Consensus Without Identity And Its Relevance In The Block Chain
Now we will discuss about the unidentified consensus in the chain of blocks. In this section of discussion, we will look at technical details of the Bitcoin consensus algorithm. Keep in mind that Bitcoin nodes do not have a long-term and permanent identity. One reason for this lack of identity is because the Bitcoin system uses peer-to-peer networks . So there is no central authority to assign a user identity. And then verify the node.
The term for this is called Sybil attack . Sybil is a potentially damaging copy of the node, and makes it look like there are many different users. When in fact all the “pseudo” users who appear different is controlled by the same person. On the other hand, the formation of a pseudonym as identity is actually also a major goal in the Bitcoin system.
Even if it is possible to establish an identity for all nodes, we certainly would not want to do that. Although Bitcoin does not guarantee full anonymity, in a transaction it is often linked together. There are properties that can not force users to reveal their true identity. Like the name or IP address of the user while participating in the Bitcoin system. It becomes an important feature of Bitcoin system design.
Let’s continue. If the node already has an identity. Then the design becomes easier. The first identity will allow us to enter that identity into the protocol. The user identity of the numeric ID must pass several steps. If the node is unidentified, there is a set of instructions that further restrict this. It is clear that there is a serious reason for the node to have an identity. This is done to improve security.
Once the identity of the node is identified, it is not a trivial thing to be able to create a new identity in Bitcoin. Furthermore, it can formulate assumptions about a number of nodes that are considered potentially dangerous. This can be done, though because of the potential nodes that do not have this identity will be a barrier protocol Bitcoin consensus.
In order for this unidentified node to be offset, it can be by making a simple assumption.Suppose how to select nodes randomly inside the system. We take the example of a lottery or lottery. Quite difficult in the lottery or lottery system to track, identity, and verify their identity. All you can do is to give them some kind of token or ticket. Then with the token or ticket can be selected ID at random. Until the caller calls the owner of the ID.
This assumption is based on a number of random nodes that allow something and is called an implicit consensus . There are several rounds in the protocol. Each one is different in the block chain. In each round, nodes are randomly selected. Next the node node proposes the next block into the block (blockchain) chain.
While there is no particular algorithm to select blocks. The selected node node unilaterally proposes what block will be included in the next block chain. However, what if the selected node is a malicious or malicious node? This implicit consensus will deal with it. Keep in mind that each block has a hash of each block that has been inserted. And this is the technical mechanism for the node to send a signal that a block has been inserted into the block chain.
Bitcoin consensus algorithm (simplified)
This algorithm is simplified. To be able to assume the ability in selecting nodes randomly, which is resistant to Sybil attacks.
New transactions are broadcast to all nodes
Each node collects new transactions into blocks
In each round, the node will randomly get its broadcast block
Other nodes accept blocks – only if all transactions in them are valid (unused, and signed)
Nodes express block receipt by entering the hash in the next block.
How will this algorithm work? To see it, we take an example. Suppose there is an attacker named Nita who wants to thwart this algorithm process. Can Nita here to steal Bitcoin from other users? The answer is not. Although Nita can propose the next block, but Nita can not steal Bitcoin from other users. Because Nita must make a completely valid transaction on the Bitcoin. In addition, Nita also had to forge the signature of the Bitcoin owner. While it can not be done Nita. So as long as the cryptography underlying this system is solid enough, then Nita can not steal Bitcoin from other users.
Denial of service attack
Now we try whether the algorithm can work if there are other forms of attack. For example, suppose Nita does not like other users named Rudi. Then nita decided not to include transactions that come from Bitcoin Rudi’s address. Furthermore, in every block proposed by Nita, he does not include Rudi transactions into the block chain. Or it could be said Nita Denial of Service Attack against Rudi.
Nita in his attack on Rudi, whom Nita tried to do is to re-arrange. While it is actually nothing more than a minor annoyance. Meanwhile, if the Rudi transaction is not included in the next block on the proposed Nita block, then Nita will only continue to wait until the opportunity block is inserted into the block chain. So it can be said that the attack by Nita against Rudi was a good attack. Because basically Nita was quite difficult to be able to enter the block proposal into the blockchain.
To be able to better know why Nita attack against Rudi is not working can be reviewed the previous discussions on the basic concept of Bitcoin .
Could be, because Nita failed to try before, then try again attack with another attack in the form of double transaction (double-spend attack). We assume in this example, that Nita is a customer of an online merchant on Rudi’s site. On the site Rudi provides online services in the form of file exchange and payment is made using Bitcoin. If payment has been made, the customer can download an application or file.
Double-spend attack will happen as follows. Nita will add some items in her shopping cart on Rudi’s website. Furthermore Rudi’s website server will request payment of Nita transactions. Once completed, Nita’s transactions are broadcast into the Bitcoin network.An honest node in the Bitcoin network will next make the next block. Including transactions in the block. One of them, is Nita payment transactions to Rudi through the site.
To remember here, that the transaction already has Nita signature. The Nita transaction contains instructions for paying transactions on Rudi’s public key and also the hash of the transaction. While this transaction hash represents the output of the previous Nita transaction pointer. That is a transaction when Nita earns Bitcoin, and now a payment transaction. While the pointer should be able to show reference to previous transactions that have occurred. Which is then inserted into the previous block on the consensus chain.
Please note also not to be confused. That here are two types of hash pointer, Block includes a hash pointer in the previous block.Transactions include one or more hash pointers in the previous transaction output.
Now let’s resume what Nita did so that she can do Double-Spend Attack. A recent block that has been generated from an honest node including Nita’s transaction to Rudi has been included in the blockchain. Rudi concludes that Nita has paid the transaction, and Nita has been able to download the application on Rudi’s website.
Suppose the next random node selected in the next round occurs and is controlled by Nita.Then Nita can propose the next block. Nita can propose the next block by ignoring the block that has contained the transactions to Rudi, and does not contain a hash pointer to the previous block. After that Nita entered the transaction she sent to Rudi to a different address on Nita’s own control.
This example is a classic double-spend example . Two transactions with the same coin, while those inserted into the block chain are only one transaction. If Nita manages to enter a payment transaction to her own address within the block chain, the transaction to Rudi becomes useless because it is not included in the block chain.
So how to know whether Nita’s efforts are successful or not? This will depend on which blocks will eventually end up in the block chain consensus structure. One on the block containing Nita’s transaction to Rudi. Or the other block containing Nita’s transaction to Nita herself.
So what determines which block to include in Blockchain? An honest node will follow a valid blockchain extension procedure. So it can determine which branch branch will be included in the blockchain. At this point, actually the two different blocks are both of the same length. Only, between the two have differences in the last block. An honest node will be able to decide which block options to include. And it is this choice that determines whether Nita’s efforts here succeed or fail.
If we only see it from the moral side, then we can see the obvious difference between the two blocks. We can see that one block contains Nita’s valid transaction to Rudi. The other block contains Nita’s transaction to Nita himself. While if we look from the technology side, these two blocks will look quite identical. So it is quite difficult to know which transaction is really valid.
In practice, nodes more often follow the block’s extension from the first sequence of blocks in a peer-to-peer network on a heuristic basis. Although it is not a definite rule. While under any circumstances, due to latent conditions in the network, it becomes easy that a block heard of the first node is the second created block. So there is indeed a chance that the next node will propose blocks that may contain multiple transactions.
On this basis Nita further attempts to increase the chances by bribing the next node to include the proposed Nita block. If the next node does not build the next block containing the double transaction, then this block chain will not exceed the length of the block containing the Nita transaction to Rudi. At this point, the next node is much more likely to forward longer blocks, and ignore blocks containing duplicate transactions. Obviously, since the block containing Nita’s valid transaction to Rudi has become more of a longer-sized block after being built on the previous node is not it?
But if the process of Nita’s efforts continues, it will be part of a long-term consensus chain.On the other hand, the block containing Nita’s valid transaction to Rudi will be completely ignored in the Bitcoin network. Such blocks are called Orphan Blocks (orphan blocks).
Now let’s look from Rudi’s point of view as a merchant in this example. How can Rudi protect himself against this double-attack attempt? Because of this side we will know how Rudi can protect himself. And from this side that is also an important part of security in the Bitcoin system for this double-spending effort.
When Nita broadcasts the transaction that represents her payment transaction to Rudi, Rudi listens to it in the Bitcoin network. And Rudi also listened to further deals from the next block. But if Rudi is more stupid than previously mentioned, then Rudi can complete the transaction process, and allow Nita to download the application at a moment’s notice.And this is called the zero-confirmation transaction. This transaction is more likely to result in double-spend attack.
Earlier, during a double-spend attack, we assumed that someone was trying to control the node to propose it to the next block. Meanwhile, if Rudi allows Nita to download the app right before the transaction payment gets a confirmation in the blockchain, then Nita can as soon as possible to broadcast the double transaction. While the next node will be able to enter the block containing the double transaction. The block containing Nita’s valid transaction to Rudi is not included.
Should, so that Rudi can protect himself from double-spend attacks, Rudi must wait until at least one or more confirmations obtained when Nita pay the transaction. On the other hand, a trader must be cautious as well when a transaction occurs, even when the transaction is already entered into the chain of blocks. If Rudi in this case can see that Nita successfully launched a double-spend attack, then Rudi can realize it because the block containing the valid transaction has become an orphan block. If that happens Rudi should not ignore the transaction, and not let Nita download the application. Conversely if that happens despite multiple transaction attempt attacks, the next few nodes will build blocks containing valid payment transactions of Nita to Rudi. Because confidence in consensus will be on the longest block.
In general, the more confirmation transactions are made, the higher the likelihood of being in long-term block consensus. Keep in mind that honest nodes tend to extend longer blocks longer when they see them in block chains. So the chances of a short block branch containing the double transaction is getting narrower.
The reality is, this double-spend will be minimized by the large number of transaction confirmations. So that transactions that have received a number of more confirmations then the chances of a double-spend attack become less. Heuritically, in Bitcoin transactions at least wait after six confirmations. Although there is no explanation in more detail that your transaction must wait for the six confirmations. The six confirmation numbers are just a guarantee that your transactions will be completely secure and can be in a long blockchain consensus.
The protection of these double-transaction attempts is entirely done in cryptography. But it also needs to be enforced in consensus. That is, that if a node tries to enter an invalid transaction, then the only reason that would deny it is some and the majority of the honest nodes will not enter the transaction as a legitimate transaction within the block chain.
On the other hand, the protection of this dual transaction effort is based on consensus. In this case, cryptography can not play much in this respect. And two transactions of which one represents multiple transaction attempts apply only to a cryptographic perspective. But the consensus determines which blocks will be included in the long-term block consensus.Ultimately, you can not be 100 percent sure that your transaction will be in a block consensus branch. But this exponential probability guarantee is good enough. At least after six confirmation of the transaction, then there is almost no chance of something going wrong next.