In the last 24 hours, the total market cap dropped by ~20% on news of a possible double spend vulnerability that had been exploited. It was quickly pointed out that the transaction was perfectly fine and no malicious activity had taken place, but as the saying goes ‘A lie can travel half way around the world while the truth is putting on its shoes‘.

Below, I will break down everything you need to know.


At the very start, we need to understand what a double spend is, and when it actually matters. The easiest analogy is to think of a Bitcoin wallet as a cheque book. Every cheque has a unique number that is used for confirming transactions. A double-spend would a someone trying to cash a photocopied cheque.

If the copy was incredibly good – same paper type and all – how would you be able to tell if it was real or not? In the case of Bitcoin, the first person to cash the cheque is declared the winner. For obvious reasons, the idea of trying to spend the same money multiple times is frowned upon.

But not all double spends are bad.


Replace-By-Fee, or RBB, was introduced into the BTC protocol in 2016 as a way for users to resubmit transactions that get stuck in the blockchains memory pool because the fees for miners were too low. As you can imagine, having a transaction stuck with no way to be retrieved was a nightmare for many, so the implementation of a process to resubmit transactions was suggested.

Every single RBF transaction is, by definition, a double spend event.

To go back to our analogy, our first cheque got lost in the mail somewhere. So we send a perfect copy of the cheque to the same person, but this time we pay more to have a courier hand deliver it. It has cost us more in fees, but at least our money got to where it was meant to go.

Importantly, the original transaction still sits in the memory for 2 weeks before finally getting purged. But the miners will continue to reject it because that money has been spent – and confirmed – previously.


If a transaction is in the memory pool with 0 confirmations (i.e. not in a block), any technical user can double spend the transaction. This is because the miners have not yet settled on which transaction is ‘true’ and eliminated all competing transactions. While not always the case, it is usually the transaction with the highest fee that is deemed the winning transaction.

At 1 confirmation, you are probably unlikely to experience impact. Although, as it this public example, there are several 1-block discrepancies in the BTC blockchain every month. These are caused when 2 competing miners ‘solve’ the block within a very short time of each other. The solution that propagates through the network fastest is usually the winner and the losing solution is orphaned. If your transaction was in an orphaned block, it will be returned to the mempool and need to be reconfirmed into the winning blockchain.

As more and more blocks are added, the more and more improbable it becomes that your transaction will fall back into the mempool. That is why the standard recommendation most people will hear is to wait for 6+ confirmations. At that point, it is functionally impossible for a transaction to be double spent.


Yes and no. There initial reporting was accurate, because as discussed above – any RBF transaction is indeed a double spend. Because 2 competing blocks contained different iterations of the same transaction, it was definitely a reportable incident as well.

Just consider how unlikely that scenario is. In a 4 week period almost 700 blocks will be confirmed, and from that there will be <10 orphaned blocks, less than 2% orphan rate. The average BTC block contains about 2200 transaction, so in the 4 weeks there will be ~1.5 million transactions. And 2 competing transactions are confirmed on different blocks within seconds of each other. We are in the ‘getting struck by lightning on the way to cash in your winning lottery ticket’ realms of unlikely.

For such an important function of the BTC network, it is disappointingly very much unknown to the majority of users. And the price drop today is an important lesson in why this features need to be given more airplay, otherwise they will be thought of as bugs.


Here is a breakdown of the 3 transactions that caused this mess. Ironically, it was the original transaction that ended up being the ‘winning’ transaction, rather than the 2 attempts at Replace-By-Fee. In Attempt #2 it looks like the user was either attempting to return the transaction to an address they controlled or resubmit the transaction to a new address of the receiver.

In the original link from Bitmex, there is an error in their reporting with suggested that the transaction was for a higher value, which would have been a discrepancy to the other 2 attempts. However when the transaction is reviewed via Blockcypher, the outputs on all 3 attempts match. This is likely due to how Bitmex displayed the output.