What happens if two miners ﬁnd a block at almost the same point in time? PoW blockchains resolve such conﬂicts called blockchain fork and how attacks might utilize this resolution mechanism to perform double spending attacks.
A fork occurs when two miners arrive at a new block at roughly the same time. Both blocks solve the partial hash inversion problem, but only one of them can be part of the long-term blockchain. The discarded block is called an orphan block. The decision of which branch of the blockchain is the valid one is not taken by any party. Rather the dispute resolves itself organically.
A blockchain fork can persist for several block. This happens when there is a split in the network, and some miners believe one branch of the fork is the legitimate blockchain, while the others follow the other branch. The protocol determines that the correct blockchain is the longest one. So miners have an incentive to stop working in a branch as soon as it is clear that it will be orphaned, because work on an orphaned branch is wasted. Therefore forks resolve themselves quickly, usually in just 1 block. The average number of forks has been around 2%, i.e. on average every 50 blocks there is a fork in the blockchain. Forks of more than one block are very rare.
Transactions included in the blocks of a fork are not lost. When a fork is resolved and a branch of the blockchain is discarded, the transactions in that branch are introduced again into the unconfirmed transactions’ memory pool, ready to be included in the next block mined. Some of these transactions might already appear in a block of the legitimate branch of the fork. In this case, these transactions are discarded and excluded from the unconfirmed transactions’ memory pool. Every fork resolution produces winners (the miners that solved blocks in the accepted branch) and losers (miners whose solved orphaned blocks). The protocol avoids having a central party or group deciding about the correct branch, in line with the decentralization philosophy of Bitcoin.
The Bitcoin protocol solves a fork in favor of the longest blockchain. Blockchain length is measured by the combined difficulty of all the blocks in the chain. If blockchain difficulty were measured by the number of blocks instead, an attacker could generate many “valid” blocks with a lower difficulty than the legitimate blockchain, thus winning the blockchain race by cheating. This is not possible, and an attacker must resort to having a significant percentage of the network hash rate at her disposal to pull off such an attack.
Blockchain fork can also occur due to differences in the code run by various nodes. One famous example occurred in March 2013 after the release of version 0.8 of Bitcoin Core, which changed the database used for the UTXO from BerkeleyDB to LevelDB. The new version introduced a subtle change in the rules of the Bitcoin protocol. This change resulted in a block being recognized as valid by the miners running version 0.8, but invalid for miners running version 0.7 of the software, creating a fork in the blockchain. As there was more computational power running version 0.8, this branch of the blockchain pulled ahead. However, this was leaving miners running the older version behind. Developers and mining pool operators discussed the course of action, and decided to revert to the branch followed by miners with the older version. Miners and users running version 0.8 downgraded to version 0.7 and reset their blockchains to that branch. Some services had to shut down temporarily while performing the downgrade to protect from possible double-spending attacks. Forks due to changes in the protocol are an exception to the rule that forks should resolve themselves organically.