What really happened in the suspected “double spend” bitcoin transactions
On Wednesday 20th January BitMEX Research alerted the world to a “double spend” on the bitcoin blockchain — essentially that someone had successfully spent the same bitcoins twice.
Considering that the prevention of double spends is the raison d’etre for the bitcoin blockchain, this appeared to be a damning event for the network.
“We propose a solution to the double-spending problem using a peer-to-peer network.” Bitcoin Whitepaper, 2008
However, whilst BitMEX’s claim was certainly alarming it turned out not to be quite as reported. Instead it was in fact a series of unlikely situations occurring together and the protocol behaving exactly as intended. Most importantly, no one was able to successfully spend the same bitcoins twice.
So what did happen?
1. A user created three transactions
Transaction Hash: a13c2bdefcd51ef2a162f232179676c848b853b11596ac3381b70726758cfd41
Transaction Hash: fab49c549e0ff2af56bdf58351e923cb1182242b7d90e563f1c0228fd7691d91
Transaction Hash: 9e19bc72f3b9bb23351311f88dc6f5c2e7a209a4fb0ad80b35d50f765e343e29
These transactions all looked to spend funds associated with the following addresses:
- 1AvroMEtvVMGd3eZ7HAHkzK7tNQScaPNJk
- 1LvTeWkoKMphqZAu1gwjkuQ4VogyKWGT3E
- 1hEnimz3T7sktS2ReY8M2iVXz4RVZNf9F
Whilst creating multiple transactions using the same inputs may be an attempt to triple spend, it could also be the activity of a legitimate bitcoiner who wishes to ‘cancel’ their transaction.
As the bitcoin blockchain is a decentralised network, there is no system administrator or operations team you can appeal to in order to cancel an already broadcast transaction. Instead you can attempt to replace it with a transaction spending the same input(s) and with a higher fee. This incentivises the miners to select this higher paying version and include it in a block instead.
In this case, it appears that the user was attempting to replace each transaction with a subsequent one of a higher fee.
2. The transactions were picked from the mempool by two different miners
Once broadcast, these transactions entered the bitcoin mempool — a waiting room for transactions which have not yet been successfully included in a block.
It is worth noting that there isn’t a single globally accessible mempool, but instead each node on the bitcoin blockchain maintains their own mempool. Therefore whilst nodes have broadly similar mempools, it is possible for one node to have transactions in their mempool that another does not.
Miners then select transactions from their mempool to include in their candidate block and begin the mining process.
In this case, F2Pool selected transaction 9e19bc… and Slushpool selected transaction a13c2b… within their candidate blocks. Transaction fab49c… remained in the mempool and was not selected for a candidate block. It’s worth noting that neither miner included more than one of these transactions in their candidate block since the validation checks a miner runs when compiling a block of transactions will prevent the inclusion of any transactions attempting to spend the same inputs.
Why SlushPool selected the transaction with the lowest fee is a valid question, however miners can select transactions based on any criteria they wish — selecting the highest fee transactions is not mandatory.
So far, everything is working as intended.
3. Two blocks were successfully mined at the same time
The mining process, to heavily simplify, is a race to find an answer to a mathematical puzzle which specifies a certain criteria. Usually one miner will find an answer first, however it’s certainly not impossible for two (or more) miners to both find a correct solution at the same time.
This creates a temporary fork in the blockchain where there are two valid blocks at the tip of the blockchain.
This is what happened to SlushPool and F2Pool. Both successfully mined their candidate block for block height 666,833 at the same time.
This meant that other miners had to select which of these blocks to build their next candidate blocks upon. However Satoshi’s rule dictates that the longest chain ‘wins’ and so once block 666,834 was successfully mined on top of SlushPool’s block, this meant that F2Pool’s was orphaned and all transaction within it which were not also within SlushPool’s 666,883 block or 666,834 were returned to the mempool.
As such, for the 5 minutes 54 between two block 666,833 being found and Binance Pool successfully mining block 666,834 it would have appeared that both transactions were confirmed (albeit with 0 confirmations).
However from block 666,834, transaction 9e19bc… was no longer valid and only transaction a13c2b… was confirmed, now with one confirmation.
The bitcoin protocol behaved exactly as intended, albeit in the face of several unlikely situations happening.
This serves as a reminder to ensure that a transaction has at least 3 confirmations (with 6 ideally) before it is considered finalised. Anything less, leaves the possibility that the block including your transaction may be orphaned and your transaction moved back into the mempool. The result of which is that a transaction you thought had occurred, has in fact not.
