Consensus without Identity: the Block Chain

Consensus without Identity: the Block Chain Let's now examine the consensus algorithm used by Bitcoin in more technical detail. Bitcoin's consensus protocol is distinct in that nodes lack permanent long-term identities. This represents a considerable divergence from the way in which conventional distributed consensus algorithms work, and if nodes have identities, it would be much simpler for a few reasons. Reasons for not having node identities One of the reasons is pragmatic. It would allow protocols to include steps such as, "now the node with the lowest numerical ID should take some action." This would be difficult to implement if nodes are entirely anonymous. A more crucial reason for nodes not having identities is for security. If nodes were identified and not attribuable to create new node identities, we could make assumptions like "less than 50% of the nodes are malicious" and derive security properties from that. For both of these reasons, the consensus protocol in Bitcoin is more difficult. Why Bitcoin Nodes Don't Have Identities In a decentralized peer-to-peer system concept, identifying nodes is challenging for two reasons. The absence of a central authority to assign identities to nodes and ensure that they are not arbitrarily generating new nodes is the first factor. The second justification is that Bitcoin aims to be anonymous. Even if it were possible, we wouldn't necessarily want to construct IDs for all nodes. Pseudonymity's Role in Bitcoin Bitcoin does not provide strong anonymity guarantees out of the box. The different transactions that you make can probably be linked together, but nobody is forcing you to put your real-life identity, like your name or IP address, in order to participate in the peer-to-peer network and blockchain. This is an important property that is fundamental to Bitcoin's design. Making a Weaker Assumption Instead of assigning identities to nodes, we can make a weaker assumption. The assumption is that there is some ability to pick a random node in the system. A good analogy for this is a lottery or a raffle where people are given tokens or tickets, which allows us to later pick a random token ID and call upon that person. We can do something similar with respect to Bitcoin nodes and further assume that the token generation and distribution algorithm has enough smarts to ensure that if an adversary tries to create a lot of Sybil nodes, all of those Sybils receive only one token. The adversary cannot multiply their power in this way. The Key Idea Implicit consensus is made possible by the presumption of random node selection and a process known as implicit consensus. A random node is selected somehow, miraculously for the time being, in each round, and there are many rounds, each one matching to a distinct block in the blockchain. Implicit Consensus Implicit consensus is a mechanism that enables the selection of the next block's miner. Miners compete to create the next block in the blockchain. The miner who solves a cryptographic puzzle first is allowed to add the block to the blockchain and receive a reward in the form of new bitcoins. However, if multiple miners solve the puzzle at the same time, then there are multiple valid blocks that could be added to the blockchain. Implicit consensus helps to resolve this problem. A random node is chosen at the beginning of each round to suggest a block. Then, the other nodes attempt to verify that block. The block is added to the blockchain and the miner is paid the reward if the majority of nodes approve it. A new round is initiated and a fresh random node is chosen to propose a new block if the majority of nodes reject the block. Implicit consensus helps to ensure that the blockchain is secure and that the majority of nodes agree on which blocks should be added to the blockchain. Without implicit consensus, the blockchain would be vulnerable to Sybil attacks and other forms of attacks. Although it is not a strict rule, nodes in the Bitcoin network often extend the block that they first learn about on the peer-to-peer network. That might very easily be the other way around due to network slowness. So, there is a possibility that the node that is selected to offer a block after you will extend a different block. Even if a trustworthy node is selected, it might be bought off or the procedure might be tampered with in some other manner. Assuming the next node extends a different block, the next honest node is more likely to extend this block, as it has now become the longest valid chain. This scenario could lead to a successful double-spend, where the network ignores the original block, which becomes an orphan block. From Bob, the merchant's perspective, understanding how to protect himself from double-spending attacks is a key aspect of Bitcoin security. Bob can either complete the transaction on the website as soon as he hears about it on the peer-to-peer network (a zero confirmation transaction) or wait until the transaction gets one confirmation in the block chain. However, even after one confirmation, there could still be an attempt at double-spending. Bob should recognize that the block he believed represented Alice paying him has been orphaned and cancel the transaction if the double-spend attempt is successful. He gains more assurance that his transaction will appear on the long-term consensus chain if the next block that is issued extends the block that he is interested in and shows that his transaction has two confirmations in the block chain. The likelihood that a transaction will appear on the long-term consensus chain increases with the number of confirmations it receives. Waiting for six confirmations is the most popular heuristic in the Bitcoin ecosystem. Consensus enforces protection against invalid transactions, so if a node tries to forge a transaction in order to steal someone else's Bitcoins, the only reason that transaction won't appear in the consensus chain is that the majority of the nodes are trustworthy and will consider that transaction to be invalid. On the other hand, double-spending protection is solely determined by consensus. Transactions that indicate a double-spending attempt appear identical from the perspective of signatures, and cryptography has nothing to say about this. Which transaction gets included on the long-term consensus chain is decided by the consensus. While there is no 100% guarantee that a transaction is on the consensus branch, the exponential probability guarantee is pretty good. After about six confirmations, there is virtually no chance that a transaction will go wrong.