Question:

How Does Bitcoin network prevent from the same transaction being included multiple time in a block

James: 2 weeks ago

Assuming that there is multiple miners in the network that have access to the same transactions that were submitted by users. How does Bitcoin network prevent from accidentally including the same transaction into different blockchain blocks? Im thinking that if multiple miners successfully mine new block at the same time (very close), the notification that some transactions were included in a block might not have propagated to others soon enough. Could this race condition cause some issues in blockchain or is this allowed to happen and then duplicate transactions are simply ignored?

Answer:
Benjamin: 2 weeks ago

First of all let's discuss what would happen if a block indeed contains a transaction that was already included in the chain:

All full nodes validate all blocks, and will not accept a block with any invalid transaction in it. If a transaction is repeated, it means its inputs are already spent by the first instance. The second one will thus be considered a double spend, and regarded as invalid, which by extension means the entire block in which it was included the second time is invalid. Thus, the entire block will simply be ignores by the network.

This means miners have a very strong incentive to not do this. It doesn't really matter how they do this, but if they risk including a transaction twice, they'd lose the entire reward (subsidy + fee) from that block if they'd win it.

Turns out, it doesn't need much to prevent it, and arguably with existing software it is much harder to do include duplicates than not. Recall that every block needs to contain the hash of its parent block. This means the miner needs to be informed of that parent block first, and gets to see it. A new block tenplate (with transaction selection) can't be constructed before the previous block is known. Since building on top of an invalid block is also invalid, software will also validate that new parent when it comes in. As a side effect, it knows about its transactions, and thus knows what a successor block is allowed to contain (which excludes duplicates of course, but also other forms of double spending).

There is sort of a shortcut that is sometimes taken in practice. When a new block is found, miners may learn about its existence faster than that its validation nodes have learned and processed the full block. In this case, a miner may instruct its hashers to temporarily switch to mining on top of an empty block (which is certainly valid). When the new parent is fully procsssed, hashers get an upgraded template with actual transactions. This can be dangerous, and has caused a significant fork of empty blocks building on top of an invalid block, around the time BIP66 activated.