When it comes to cryptocurrency, trust is everything. If people don’t believe that a cryptocurrency is secure and trustworthy, that cryptocurrency will never have much value. Before investing in any cryptocurrency, one always wants to know whether it is secure. The key to understanding blockchain security is to understand a group of problem called “the double-spending problem."
There is a lot of confusion around the double-spending problems regarding what it is, how it is carried out and how to address them. The main reason for this confusion is that there are more than one type of double-spending problems. But essentially, all the double-spending problems boils down to altering the history of transactions recorded on the blockchain:
The attacker buys something from a vendor in a transaction with some bitcoins, while creating an alternative transaction sending the same bitcoins back to himself. Then the attacker manages to get the second transaction onto the blockchain before the first transaction. Since the blockchain only allows bitcoins to be spent once, only the second transaction will be recorded on the blockchain, and the first transaction will be rejected. Hence, the vendor will ship his product to the attacker, without having this transaction recorded on the blockchain, thus not receiving any pay for his product.
Above is the gist to the class of double-spending problems. If you didn’t fully understand it, don’t panic, I will now go into a few examples explaining different variations of the double-spending problem.
Type 1: The Finney Attack
The Finney attack involves adding to the blockchain a transaction that credits oneself while spending the double-spending the same credits in another transaction, which will later be invalidated. What do I mean?
Let’s say attacker Joe has 50 bitcoins in his wallet.
For example, Joe first create a block on his local computer, and in this block, he includes a transaction that sends himself 20 coins, let’s call this transaction A. Now remember, in order to get this block added to the blockchain on the network, he has to include a proof-of-work. So he starts mining for the proof-of-work right away. As soon as he has the block ready to add to broadcast to the network, he buys a house from Joanna using the same 20 coins as before, let’s call this transaction B. Now this is the key part: While the unsuspecting Joanna transfers the ownership of her house to Joe immediately, this transaction B will not be recorded on the blockchain network. What actually happens is that the blockchain will first add Joe’s block which only includes transaction A, in which Joe sends himself 20 coins, then in the next few blocks or so, the blockchain see transaction B, which tries to transfer the same 20 coins to Joanna, the blockchain will reject transaction B because it is later on the timeline.
So, on the one hand, Joe will end up with the same amount of money he started with, 50 coins, because he took 20 coins out of his wallet to pay himself 20 coins, except now he is the legal owner of Joanna’s car. On the other hand, Joanna is no longer the legal owner of her car and she never gets the 20 coins as compensation because transaction B was rejected by the blockchain network.
Solution:
To prevent this tragedy, Joanna should wait until the transaction B is confirmed by the blockchain network before transferring the ownership of her car; if transaction B is invalidated by the blockchain network, she should not transfer the ownership of her car.
Type 2: The Race Attack
Race attack is similar, but it involves sending two versions of transaction in rapid succession in the network rather than mining one’s own block. Let’s continuing with the Joe and Joanna example.
Joe makes sure that Joanna sees only transaction B (in which Joanna gets paid). He accomplishes this mainly by surrounding Joanna’s node with his colluding nodes. If Joanna is not careful, she will transfer the ownership of her car right away. Meanwhile, Joe sends to the rest of the network transaction A (in which he sends coins to himself). When the blockchain peers receive the two transactions that conflict with each other, they will only validate the one that reaches them first. Therefore, if transaction A manages to reach the majority of the network first, it is much more likely to be included in the blockchain and confirmed first.
Solution:
Same as above. Joanna should wait until transaction B is validated by the blockchain.
Type 3: The Majority Attack (AKA 51% Attack)
This is perhaps the most famous and powerful form of attack on blockchain because it has a 100% success rate. If a miner possesses more than 51% of the total computational power in the blockchain network, he is able to mine faster than everyone else and he can create an alternative chain of blocks to be accepted into the blockchain.
Let’s say at the beginning of Joe’s attack, the blockchain is at block #5000. Joe gets to work and starts to mine block #5001, block #5002, block #5003 in which he pays himself a certain amount of coins without publishing these blocks.
Meanwhile, he buys all sorts of things from other people with the same coins. He buys a private jet, a Catamaran, a car, and all these transactions are recorded on the public block #5001, #5002, #5003. (of course he actually need the coins to be able to complete this step, but at the end he will not lose any of his coins) This doesn’t matter to Joe. He keeps mining until his chain is longer than the current public chain. So if currently the public blockchain is at #5005, and Joe finally got a chain that’s from #5001 to #5006 (6 blocks long), he can release this chain onto the blockchain network. The blockchain network will replace the original #5001 to #5005 and add #5006. Now in this new version of the blockchain, Joe has not paid anything to other people.
Now, one doesn’t necessarily need 51% of computational power in the network to carry out a similar attack. In fact, 51% attack is a special case of the more general “alternative history attack” class operating on the same principles. The success rate of carrying out the alternative history attack decreases when you have less computational power. If the attacker only controls 10% of the power and the vendor waits 6 confirmations before shipping the product, his success rate is on around 0.1%.
Solution:
In the case of 51% attack, there’s pretty much nothing one can do on the individual level. However, such an attack is unlikely because if someone controls that much computational power, he can profit more from actually mining rather than attacking the system.
Conclusion
The farther into the blockchain, the harder it gets for someone carry out a alternative history attack. Given that the attacker has to race against the other miners to create a longer chain of blocks, if he has less than 51% of computational power in the network, the more blocks are added to the public blockchain after the initial transaction, the lower the probability of successfully creating a longer chain of blocks privately. Many blocks later, the probability of creating an alternative history of blockchain approaches zero. Therefore, if you are a merchant, wait a few blocks before shipping out your goods!
