Jason C


Double Spending a 0-Conf Bitcoin Transaction 2018-04-02

There's a lot of debate about the security of 0-conf transactions. A coffee shop doesn't want to wait ~10 minutes for a block to be mined before considering a payment valid. Lots of people, myself included, like the idea of 0-conf and think its security is a crucial part of Bitcoin being a successful peer to peer cash system.

The hypothesis I see mostly thrown around is that a 0-conf double spend would cost about $60,000 and can only be executed by a miner. The basic idea is that the attacker broadcasts a transaction and then a conflicting transaction is mined. Not only does this require getting a miner to do your dirty work, everyone can see what happened and potentially penalize the miner.

Discovery

While testing out a project, I was sending low-fee transactions but they weren't propagating to my receiver wallet in Electron Cash. Making sure there wasn't a bug in my code, I sent a normal fee transaction to see if it worked. The normal fee transaction almost immediately propagated and showed up in Electron Cash.

Later when the next block was mined, suddenly my transaction in Electron Cash disappeared and was replaced by the earlier low-fee transactions I had been sending. Expecting I had done something wrong, I didn't immediately think too much of what had just happened. In fact, others have run into a similar situation before.

The Exploit

I later realized that a double spend had occurred. When most people think of double spend they assume the victim receives the first transaction and that the double-spend occurs afterward. In this scenario, it's the opposite, the double-spend is sent first but is hidden from the victim due to its low fee.

The magic here is exploiting the different minimum relay fees of bitcoin nodes. By sending out a low-fee transaction first, it is only propagated by nodes which have a low minimum relay fee. Since most wallets and nodes have a minimum fee of 1 sat/Byte (e.g. Bitcoin ABC), this "pre-spend" is unknown to them. However, a certain percentage of miners are allowing low-fee transactions, so there's a good chance this transaction will get mined.

Later on, when you make your transaction with your victim, you use a normal fee, so all 1 sat/B nodes think it's the first transaction they've seen. However, the low-fee nodes already have a conflicting transaction, so they reject this second transaction.

Conclusion

The only way I can think of to defend against this type of attack is for all wallets to have their minimum relay fee set to zero so they can monitor all transactions and check for pre-spends. As of now, I know Electron Cash is vulnerable to this, but I have not checked other wallets.

View the follow up post: BIP-133 0-Conf Double Spends on BCH.


← Back to all blog posts