Bitcoin Cash has been busy celebrating its successful bi-annual hard fork that happened back in May, but it appears as if there was a huge bug in the code that was deployed. On the day of the hard fork, three separate incidents took place, first was a 2-block reorganization, before we saw empty blocks and finally an asymmetric chain spilt. It’s likely that all of these issues either came from a bug in the hard fork code or a well-orchestrated mining attack on the network. It appears as if only 3,392 BCH was double spent as the network issues unfolded, but the only victim of the double spending attack was the attacker himself.
Empty Blocks All Around
Immediately after the hard fork, a string of empty blocks began to appear and it looks like it was due to a bug in the code. It’s beginning to look like the validity conditions for transactions to enter the mempool may have been less strict than the consensus validity conditions – the opposite for how Bitcoin and Bitcoin Cash are supposed to work. Simply put, this bug makes double spending easier, as an attacker can easily create a transaction that satisfies the conditions to be relayed across the network and get into a merchant’s mempool, but fails the consensus validity conditions to get into valid blocks – hence why the transaction validity conditions are supposed to be tighter than the consensus validity conditions.
When miners tried to add these to the network and create new blocks, they discovered that the transactions were in fact invalid, so they created empty blocks as opposed to no blocks at all – like the Stellar Network does.
The Dreaded Asymmetric Chain Spilt
At block 582,679 we saw the Bitcoin Cash hard fork take place, but due to the bug in the code and the empty blocks, miners were unsure what to do. The empty blocks caused concern and confusion, so a number of miners reverted back to the pre-fork conditions, creating an asymmetric chain spilt. Yet, it appears as if the hard fork was not a “clean split” as when run in a test environment, a Bitcoin Cash node will accept the pre-fork chain, as well as the post-fork chain. This could indicate another greater vulnerability in the Bitcoin Cash network code and open doors for future attacks during hard forks.
A Coordinated Two Block Reorg
Back in April, the Bitcoin Cash community laughed at Bitcoin SV after it was hit by multiple block reorgs in two separate 51% attacks. However, the shoe is on the other foot now, as Bitcoin Cash suffered a coordinated two block reorg just after the hard fork. The orphaned block 582,698 contained 137 transactions- including the coinbase – and during the second block reorg only 111 transactions made it into the winning chain This means there were 25 transactions that simply went missing. The value of these 25 transactions comes to around 3,392 BCH, but fortunately the only person affected by this attack was the hacker himself. It’s still unclear as to whether the block reorg was down to a group of miners testing the new SegWit recovery system during the hard fork.
Fortunately, during the double spend attack, no merchants were harmed. But, it does highlight the vulnerabilities in Bitcoin Cash and the potential downsides of having a bi-annual hard fork. Hopefully, the Bitcoin Cash development team can work on removing more bugs before the next hard fork goes live in October.
