Demystifying Bitcoin White Paper
“The Times 03/Jan/2009 Chancellor on brink of second bailout for banks.”
In October 2008, a paper surfaced with the title Bitcoin: A Peer-to-Peer Electronic Cash System. This paper was authored by the mysterious Satoshi Nakamoto, whose identity still remains unknown. This paper was the first of its kind and it started the Blockchain Revolution.
Introduction
Physical money allows one to transact without any external trust agent. But the current system for digital transactions suffers from the inherent weakness of a trust-based model.
- High transactions cost, as banks cannot avoid mediating disputes.
- Transactions can be reversible if the banks decide so.
- Merchants often ask for more information than that is needed.
There is a need for an electronic payment system where ‘trust’ is implemented into the system by using cryptographic proofs. In this system, transactions would be impractical to reverse and routine escrow mechanisms could be easily implemented to protect buyers. Since trust is built-in, the transaction costs are also reduced.
Transactions
The electronic coin can be considered as a chain of digital signatures of previous owners. Each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key of the next owner and adding these to the end of the coin. We just need to verify if all the previous owners signed earlier transactions.
Double Spending Problem
Someone might try to add two transactions that consume the same output, this would lead to a double spend attack. To avoid this, we track current Unspent Transaction Output (UTXO) and whenever a new transaction is noticed, we check if the inputs are unspent or not. To solve the double-spend problem, we just need to consider the first transaction and process it. Consequently, all later attempts to use the same input will fail as it will not be present in current UTXOs.
It is easy to decide upon the order of the transactions in a centralized setting but in order to accomplish without a trusted party, all the transactions need to be publicly announced. We need a system by which the majority of participants can agree upon a single history of the order of transactions.
Timestamp Server
Every block or transaction includes the current system time and its hash is publicly announced. This hash can be considered as a timestamp as it indicates that the particular data existed at a particular time. Thus, no one can later generate a block or transaction with the same data but a different time. This ensures that no one can change the order of transactions, once the transactions are publicly announced.
Each block or transaction also includes the previous timestamp, thus forming a chain. It must be noted that a hash depends on the previous hash(s). Thus, every new block or transaction reinforces the ones before it.
Proof of Work
To implement a timestamp server on a peer-to-peer basis, one needs to provide proof which would consume some resources. Without any “cost” associated in the generation of the block or transaction, the system would fall prey to spam which could lead to a potential security threat. In Bitcoin, the user needs to submit a proof which can only be generated by spending computational resources and thus is called proof-of-work.
Another data field named nonce is appended to blocks such that the hash of block starts with a required number of zeroes. Given that we are using a good hash function, the only way to calculate such a value which satisfies the above condition is to try different values randomly. It must be noted that the difficulty of finding such a nonce increases exponential with the number of leading zeros. The existence of nonce proves that the user has spent its computational resources to vouch for the data present in the block, thus can be “trusted”. The process of finding a valid block is called mining.
This also increases the data integrity of the block, as the block cannot be changed without redoing the “work”. Also, as more blocks are added to the chain, the “work” needed to change this block increases (Hint: Timestamp of the previous block is included in the block). By using this kind of mechanism bitcoin promotes one-CPU-one-vote rather than one-IP-address-one-vote. This decision was made because one can spawn multiple fake IP addresses but cannot fake CPU power.
The majority decision is represented by the longest chain i.e. chain with the greatest amount of proof-of-work. Thus, as long as the majority of the CPU power is controlled by the honest nodes then the network will proceed correctly. As hardware improvements occur, the required number of zeroes or otherwise known as the proof-of-work difficulty is increased. To be precise, the proof-of-work difficulty is revised after regular intervals such that the average number of blocks per hour remains constant.
Network
The network operates in the following way:
- New transactions are broadcast to all nodes.
- Each node collects new transactions into a block.
- Each node works on finding a proof-of-work for its block.
- When a node finds a proof-of-work, it broadcasts the block to all nodes.
- Nodes accept the block only if all transactions are valid and are not already spent.
- Nodes express their acceptance of the block by working on creating the next block in the chain, using the hash of the accepted block as the previous hash.
It is not necessary (nor required) that every transaction or block will reach every node. If a node doesn’t receive certain transactions or block, then it will request for it from the network when it receives a later block and realizes it missed some block.
Consensus
A node considers the longest chain to be the correct one and hence it keeps on “working” to increase it. In the network, it is possible that multiple blocks are broadcasted simultaneously. In this case, the node will accept all the blocks (if they are valid) and create branches in the current chain. The tie between different branches will be broken when one branch becomes longer than the others.
Incentive
Incentive must be provided to encourage honest behaviour. Also, an incentive must be provided against the CPU time and electricity expended by the node. Every block contains a special transaction that creates a new coin that is owned by the creator of the block, thus compensating for the resources spent. Also, this helps to distribute coins without any central authority. Another incentive for the miner can be transaction fees.
Although, there is an upper limit to the number of bitcoins that can be in circulation i.e. 21 million. The reward for mining the block is halved every 210,000 blocks (roughly 4 years) so as the system grows the incentive can be gradually shifted from new coins to transaction fe+es.
Consider that an attacker is able to assemble more CPU power than all honest nodes. As the attacker controls the majority of the CPU power, the attacker will produce more coins than everyone else combined. By making fraudulent transactions, the attacker will undermine the value of a system and consequently his own wealth. Thus, the system is designed in such a way that an attacker will find it more profitable for him to play by the rules.
Reclaiming Disk Space
Once the latest transaction in a coin is buried under enough blocks (Remember: a coin is a chain of transactions) i.e. the transaction can be considered irreversible and true, earlier transactions can be discarded as they are of no relevance for the future of the system. Note that this is not a necessary feature but is implemented because of space optimization purposes.
But we cannot remove previous transactions from the history as it will change the hash(s) of previous blocks, thus making them invalid. To solve this problem, the paper proposes to construct a Merkle tree and store the Merkle root hash in the block header.
Whenever transactions are being deleted or pruned, all the branches that are not needed by other transactions for verification are deleted i.e. inner hashes do not need to be stored.
Simplified Payment Verification
You don’t need to run a full network node i.e. keep a copy of the full blockchain (197 GB, as of the writing of this blog) but just keep a copy of block headers of the longest chain, which can be obtained by querying the nodes. Note, one needs to query multiple nodes to make sure that the data it is keeping indeed belongs to the longest chain.
For locating a transaction, the user needs to obtain all the hashes of Merkle tree that link the transaction to the block header of the block it’s timestamped in. A user can ‘check’ the transaction by locating the transaction in the chain (this proves that the transaction was accepted by a node) and by counting the number of blocks added after it (this proves that the transaction was accepted by the network). Currently, 6 block confirmations are considered secure for practical purposes.
Consider that an attacker is able to overpower the honest nodes. It can fool such a simplified payment scheme by sending fabricated transactions as unlike network nodes, this system cannot verify the transactions itself. The paper proposes that this system could accept alerts from the network nodes when they detect an invalid block. When this system receives an alert, the system will download the full block and relevant transactions in order to confirm the inconsistency, thus ‘verifying’ the alerted transactions.
Combining and Splitting Values
Just like traditional currencies, the bitcoin can be split into smaller coins or be combined into a larger coin. To allow combining and splitting of coins, the transactions need to contain multiple inputs and outputs. There could be one or more inputs in a transaction and at most two outputs: one for the payment to another user and another for returning change to the user.
As it might happen that a transaction depends on multiple transactions and those depends on others, we do not need to traverse through the whole tree as we track the UTXOs and they account for every currently in circulation.
Privacy
One might think that since every transaction is publicly broadcasted, there is no privacy provided by the system. But privacy can still be maintained by using anonymous public keys and encrypting transactions. The public can see the time and size of the transactions, but cannot link it with the owner. Although some linking is unavoidable with multi-input transactions, which reveal that their inputs were owned by the same owner. Once the key is revealed, linking could reveal other transactions made by the same owner.
It is recommended that the user should use a new key pair for every new transaction. Although, it must be noted that this ecosystem is not actually anonymous but is pseudonymous i.e. one cannot simply connect the public keys back to the user in the physical world. It is possible for an attacker can connect the user with keys via some transaction patterns (this will only happen when the user doesn’t change or manage keys appropriately). Although, current privacy models also don’t offer much privacy on this front.
The Way Ahead
- Ethereum White paper
- Distributed Ledger technology: The Science of Blockchain by Roger Wattenhofer
- Mastering Bitcoin: Programming the Open Blockchain by Andreas M. Antonopoulos
- Bitcoin and Cryptocurrency technologies by Princeton University
- Blockchain: Understanding its Uses and Implications by The Linux Foundation
About Narendra:
Narendra is a CSE undergrad who got interested in blockchain in mid-2018. His interests lie in cryptography and distributed systems.
About B@I:
Blockchain At India is a community formed by blockchain enthusiasts who aim to inspire university undergraduates from every nook and corner of the country to try their hands out at blockchain by providing the necessary motivation, drive and resources.
