No, Bitcoin Was Not Double Spent

Yesterday, BitMEX Research mistakenly reported a double-spend involving block 666833. In a tweet, BitMEX claimed that bitcoin had been double spent as a result of a block reorganization. Interpreting this event as a double spend is a mischaracterization and misleading use of terminology.

What Is a Double Spend?

A double spend occurs when the same unspent transaction output (UTXO) is used in multiple transactions that were recorded in the Bitcoin blockchain. In other words, the same bitcoin was spent multiple times. A double spend would violate the Bitcoin protocol.

If the BitMEX report had been true, the assumption that Bitcoin had solved the Double Spend Problem would have been nullified and Bitcoin’s reliability would have been permanently compromised. Fortunately, yesterday’s report of a double spend was incorrect and no double spend actually occurred. The Bitcoin protocol worked exactly as intended.

What Actually Happened

In actuality,  there were briefly two competing chains, which had different versions of the same transaction. This occurred because two miners solved the Proof-of-Work puzzle near the same moment, and each had a different version of the transaction in their block. They then sent their block to the rest of the Bitcoin network. Other miners chose the first block they saw and tried to mine (extend the bitcoin blockchain by finding a hash value using pending transactions and the one of the competing blocks). When miners found the next block, the ambiguity was resolved. This series of events has occurred many times in the past, most recently on January 7, 2021, and at no point was Bitcoin at risk of allowing a double spend. Let’s follow the process in greater detail:

First, an unknown Bitcoin user submitted two versions of the same transaction using Bitcoin’s Replace-by-Fee feature. Both transactions were valid at creation, however, they were both attempting to spend the same UTXO, and thus could not both be included in the blockchain. Eventually, one would be valid and the other would be discarded.

Second, F2Pool, a mining pool, included one version of the transaction in block 666833. This made the other transaction ineligible for inclusion in any future blocks.

Third, at almost the same time, SlushPool, another mining pool, mined an alternative version of block 666833. This event, likely unintentional, is a relatively common occurrence on the Bitcoin network. SlushPool’s version of block 666833 included the second version of the transaction in question.

At this point, there were two separate forks of the Bitcoin blockchain, each with different versions of the same transaction. Only one of the two chains could be valid, but the Bitcoin network had not yet reached a consensus on which one would be valid and which would become an orphan block.

Whichever chain the next block was added would likely decide which of the two competing versions of the transaction was valid. Regardless, both transactions could never have become valid and included on the same chain.

How Was This Fork Resolved?

Bitcoin nodes always consider the longest chain as the valid chain, and Bitcoin guarantees that no UTXO can be double spent in the same chain. When both chains had 666833 blocks, both chains were equally valid.

Ultimately, it was SlushPool’s version of block 666833 which was used to mine block 666834, making SlushPool’s block 666833 valid and rendering F2Pool’s block stale or orphaned. As a result, the version of the initial transaction included in F2Pool’s block was also rendered invalid.

Avoiding Double Spends

No double spend ultimately occurred. For a brief time, it might have seemed as though the initial transaction was confirmed, when it was ultimately rejected and replaced with the alternate version of the transaction. This could potentially cause problems for merchants who believe they have been paid before the transaction was rolled back at a later time.

This incident underscores the importance of waiting for multiple confirmations before considering a transaction to be settled with finality. In the above example, only one block was orphaned, an event which occurs roughly every 1000 blocks. In extremely rare cases, 2 or even more blocks might be orphaned at a time. Thus, by waiting for 6 confirmations, the risk of trusting a transaction that is later reorganized out of the blockchain is reduced to almost zero.