Blockchain
Double Spending
Any transaction can be processed only in two ways.
·
One is offline, and
·
another is online
Offline:
A transaction which involves physical currency or cash is known as an
offline transaction.
Online:
A transaction which involves digital cash is known as an online
transaction.
Double
spending means spending the same money twice. In a physical currency, the double-spending problem can never
arise. But in digital cash-like bitcoin, the double-spending
problem can arise.
Understand Double Spending Problem
·
You go to
Restaurants and order a cup of Tea worth Rs 5. You pay in cash. The service
provider at Restaurants instantly confirmed that you have paid, and you
received your Tea in exchange for the money.
·
Now is it
possible to spend the same Rs 5 somewhere else to make another purchase?
·
The answer
is NO.
·
But what if the
answer is YES?
·
It means the same person can use the same cash more than one times.
·
This type of
problem is known as Double Spending Problem.
Why is double spending an issue for digital money?
· Digital money is different from cash.
· When make a transaction with digital cash, there are broadcasting the
transaction to all the ‘nodes’ in the network.
·
Actually,
nodes need to receive and confirm the
transaction, which takes time.
· Hence there is the problem:
o
What is to stop someone copying a
transaction and rebroadcasting it before it’s been
confirmed on the network?
o
How would the network know which
transaction was genuine?
Bitcoin does not have a central bank to mediate disputes.
·
Prior to the invention of bitcoin, digital
money flowed across the internet. It was all monitored and controlled by banks
and financial institutions, just as most of it is to this day.
·
The problem with banks acting as mediators
in financial disputes is that transactions can be reversed if a dispute occurs.
·
This leads to higher fees and slower
transaction times. Bitcoin
aimed to solve these limitations by creating a system based entirely on
cryptographic proof, instead of trust. In effect, it offered a way to do
banking without the banks.
Every bitcoin shows the chain of ownership.
·
To begin to understand how this system of
cryptographic proof works, it is essential to understand what a bitcoin actually is.
·
In the bitcoin white paper, a bitcoin is
defined as a chain of digital signatures.
o It can move from one owner to the next via digital wallets. Each wallet
has a public key (an address) and a private key (a confidential password
that only the owner knows).
o When one bitcoin owner transfers a coin to someone else, they sign a
hash of the previous transaction and the public key of the next owner.
o This hash is then added to the end of the bitcoin. Therefore, every
bitcoin is like the log book for a car — it contains a record of all previous owners.
Bitcoin’s blockchain is a universal ledger.
·
To manage the double spending problem,
bitcoin relies on a universal ledger called a blockchain.
·
To prove that no attempts
to double-spend have occurred, the blockchain provides a way for all nodes to
be aware of every transaction.
·
With bitcoin, all
transactions are officially announced to all nodes. They can then agree on a
single history of the order in which they were received.
·
Bitcoin’s solution to
double-spending is that if the majority of the nodes agree on which transaction was first to
be received, later attempts to double-spend are irrelevant.
Bitcoin Script is a simple, stack-based
programming language that enables the processing of transactions on the Bitcoin
blockchain.
·
Bitcoin Script is a simple programming language used to
interact with the Bitcoin software.
·
In particular, Script gives the Bitcoin software
instructions on how coins in a UTXO (Unspent Transaction Output) can be spent.
·
Of course, most users never need to learn Bitcoin Script.
·
Wallets and other Bitcoin applications complete all the
processing behind the scenes automatically.
Stack-based
· Bitcoin
Script uses a data structure that can be thought of as a linear structure
represented by a physical stack.
·
· Imagine
stacking three books:
o
Book A (top),
o
Book B (middle), and
o
Book C (bottom).
· With
Bitcoin Script, Book A would need to be the first taken out of the stack
(popped), followed by Book B and Book C, to put anything at the bottom of the
stack (pushed).
· The same
concept is applied virtually to operations in a sequence with Script.
· Script
resembles Forth, a
programming language that first appeared in 1970.
· Forth is
used in the Open Firmware Bootloader, space applications (including the Philae
spacecraft), and a variety of other embedded systems involving interactions
with hardware.
· Also
known as postfix notation, RPN is a method of placing the operation function at
the end of a sentence. For example, adding 5 and 6 in Script must be written as
“5 6 +” rather than “5 + 6.”
· Turing
incomplete means that Script does not allow infinite loops.
· This has
both advantages and disadvantages.
· One
advantage of using a Turing incomplete language is the inability to run
malformed scripts, regardless if they are intentional
malicious attacks or unintentional programming errors.
· Essentially,
Script is able to prevent the halting problem. Other
blockchains developed since Bitcoin have mainly chosen to be Turing Complete,
or at least have a high degree of Turing completeness.
· Although
this potentially brings the halting problem into play, it also provides better
support for the complex logic required for developing smart contracts.
· In order
to make this transaction happen, Say a person RAMA
needs to get bitcoins which he has received from various previous transactions.
Remember, like we said before, in bitcoins, each and
every coin is accounted for via a transaction history.
· So,
suppose RAMA needs to pull bitcoins from the following transactions which we
shall name TX(0), TX(1) and TX(2). These three
transactions will be added together and that will give you the input
transaction which we shall call TX(Input).
So, that is it from the input side, let’s check out what the output side will look like.
Now,
this is a very simple transaction that has just one
output (apart from the CHANGE), there are transactions that are possible with
multiple outputs.
This is
what the basic layout of the transaction looks like. For this entire thing to
go through, however, certain conditions must be met.
·
TX(Input) > TX(output). The input
transaction has to be always greater than the output
transaction. In any transaction, the deficit between the input and the output (output+change) is the transaction fees that miners collect.
So:
Transaction fees = TX(Input) – (TX(output) + Change).
·
In the input side:
TX(0) + TX(1) + TX(2) = TX(Input).
·
If RAMA doesn’t have the funds necessary to carry out the transactions then the miners will simply
reject the transactions.
·
Ravi will have to show that he can provide the proof needed to get the
bitcoins. RAMA will lock the transactions with Bob’ public address. He will need to
produce his private key to unlock the transactions and gain access to his fees.
·
RAMA also needs to verify that he has the required rights to send over
the bitcoins in the first place. The way she does that is by signing off the
transaction with her digital signature (aka her
private key).
·
Anyone can decode this by using her public key and verify that it was
indeed Alice who sent over the data. This proof is called “Signature data”. Remember this
because this will be very important later on.
So, what is going to be the name of this entire transaction?
The Input
(including the signature data) and the output data is added together and hashed
using the SHA 256 hashing algorithm. The output hash is the name that is given
to this transaction.
So, now lets a look behind the
scenes and see what the transaction actually looks
like.
The above
example is a simplified explanation for how Bitcoin Script works to support transactions
on the Bitcoin network. If you examine a standard locking script for scriptPubKey on a Pay To PubKey Hash (P2PKH) transaction, you will find something a
bit more complex like:
OP_DUP OP_HASH160 <371c20fb2e9899338ce5e99908e64fd30b789313>
OP_EQUALVERIFY OP_CHECKSIG
Above, there is an example of
how a commonly used script looks.
Noticed that “OP_” is used a
lot. This prefix is used to identify operation codes, more commonly referred to
as Opcodes. Simply put, opcodes are commands that tell nodes in the Bitcoin
network how to deal with any specific transaction request.
Let us look at a few of the most
common ones.
OP_ADD: Pops two items off the stack,
adds them together, and pushes the result back onto the stack.
OP_EQUAL: Pops
two items from the stack and compares them to check if they are equal. if they
are equal, then it pushes the result TRUE back onto the stack.
OP_RETURN: Can be
used to store up to 80 bytes of arbitrary data on the Bitcoin blockchain and also to mark a transaction output as invalid. OP_RETURN
transaction outputs
are provably unspendable, making this opcode an
efficient way to burn BTC. It also makes Komodo's delayed
Proof of Work (dPoW) security
mechanism possible.
OP_CHECKSIG:
Verifies that the signature for a transaction input is valid.
OP_CHECKMULTISIG:
Commonly used in Pay
to Script Hash (P2SH) transactions. OP_CHECKMULTISIG looks at
3 public keys and 2 signatures in the stack and compares them one-by-one. Funds
become spendable only when the order of the signatures matches the order in
which the public keys were provided.