Double spending and immutability in blockchain

In the last article, we looked at the process of mining in blockchain in depth. This article will look at how blockchain avoids double spending and how it manages to be immutable.

Before we learn about double spending and immutability, let’s take a quick recap of the Proof-of-Work algorithm. The process of trying to produce a hash below a target hash forms the Proof-of-Work algorithm. Since miners expend their CPU time to find the correct hash value, when a miner mines a block with a hash value below the target hash value, it serves as proof of the miner having done some work. Here the work is the processing time of the CPU.

We call the Proof of Work a consensus algorithm because it helps reach a consensus on what the next block should be. A consensus algorithm should be such that it should be hard for anyone to solve the puzzle, but it should be easy to verify the solution. This is exactly what the Proof-of-Work algorithm does. It’s difficult to produce the right hash. But once produced, we can easily verify if it is less than the target hash.

Double spending

While allowing us to have a single source of truth, the Proof-of-Work algorithm also helps protect against double-spending. In order to understand how it works, let’s go back to our bookshop example. Let’s say after sending money to the bookshop, we are now planning to send the same money to a restaurant to buy food. As you may have already guessed, this wouldn’t work since my transaction to the bookshop is now in the blockchain. So, we can’t reuse the same inputs.

Therefore, in order to be able to double spend, we should be able to attach our new block to the block that comes before the block that has the transaction to the bookshop. To do this, our new block should in its header refer to the block that comes before the block that contains the transaction to the bookshop.

This is possible but very difficult since there is no guarantee that we will be able to mine a block. Remember, the probability of mining a block depends on the hash rate of the miner. But let’s assume, we have indeed managed to mine the new block. Now, there is a fork. Our blockchain has two branches. Whenever something of this sort happens, nodes in a blockchain will always choose the longest branch and discard the others.

Hence, we need to produce another block to make our branch longer so that other nodes can accept ours as the right branch. Since the other branch is older than our new branch and all the miners have been mining on that branch, they would continue doing so. This means it is completely up to us to produce the next block on our branch. Thus, I will have to be lucky twice in a row to be able to double-spend.

Confirming transactions

Still, this is not completely impossible. This is why it is advisable for recipients to wait for a few more blocks before confirming and accepting the transaction. So, in the case of the bookshop, they should ideally wait for a few more blocks, usually six, before shipping the purchased book.

After miners add six more blocks, to double spend, we will have to mine eight blocks in a row to be able to create a longer branch. We need eight blocks because we will have to overtake seven blocks (the block carrying the transaction to the bookshop + six blocks added subsequently) and mine one more block to make the new branch longer. That’s impossible and it effectively prevents double-spending.

Immutability

Remember, in a previous article, I said that the time spent to mine a block is not a waste and compared it to a restaurant taking its time to prepare a dish? This is the reason. The ten minutes invested in mining a block actually make a blockchain immutable. The longer it takes to mine a block, the more energy a miner will have to expend. So, the cost of trying to double spend outweighs the potential benefits.

In order to modify a block in the blockchain, we have to modify all the subsequent blocks. This is because every block refers to its previous block using hashes. When we modify a block, its hash changes. As a result, the reference to the previous block in the subsequent block becomes invalid. So, we have to update this reference with the new hash in the subsequent block. This would change the hash of the subsequent block. Likewise, we have to modify all the subsequent blocks.

Even though I can modify my blockchain, I can’t convince other nodes to do the same. The only way I can do so is to create a longer branch. To do it, I should be able to mine several blocks in a row. However, this becomes tougher as the number of blocks increases. If the block to modify is 70 blocks from the end of the chain, then I will have to produce 71 blocks in a row. This is impossible. Hence, the deeper a block is buried in a blockchain, the more immutable it becomes. This immutability is what makes double spending difficult.

In this article, we looked at double spending and immutability in blockchain. In the next article, let’s look at forks in blockchain and how we resolve them.