Research: Bitcoin Cash Hardfork Plagued by Three Key Issues

As reported by BTCManager earlier in May 2019, the Bitcoin Cash network went ahead with its hard fork as earlier planned. However, the event was nearly scuppered by a bug on the Bitcoin ABC client which rendered the chain non-functional for several hours. Now, a BitMEX research report on May 24, 2019, has revealed three significant problems that plagued the Bitcoin Cash Hardfork.

Attack Transactions

According to the researchers, the Bitcoin Cash hard fork of May 15, 2019, suffered from three interrelated problems: a loophole exploited by an “attack transaction,” which caused miners to produce empty blocks. The fear, uncertainty, and doubt (FUD) brought about by the empty blocks made some miners to boycott the chain, mining on the “original non-hard fork chain instead.

This scenario further resulted in a consensus chainsplit, a situation whereby different nodes end up on different chains.

The researchers have also pointed out that miners and developers on the Bitcoin Cash network tried to recover funds mistakenly sent to SegWit addresses, however, the weakness in the chain made it impossible, resulting in a “deliberate and coordinated 2 blockchain re-organisation.

BitMEX said:

“According to our calculations, around 3,392 BCH may have been double spent in an orchestrated transaction reversal, but the only victim with respect to these double spent coins could have been the original ‘thief.’”

Three Major Issues

Reportedly, the Bitcoin Cash hard fork upgrade experienced three critical problems: empty blocks, an asymmetric chain split and the coordinated two block reorganization, two of which were likely caused by a bug that triggered the production of empty blocks.

A severe bug in the Bitcoin ABC chain, a vital software implementation for Bitcoin Cash, caused the “validity conditions for transactions to enter the memory pool to be less onerous than the consensus validity conditions.”

A rogue actor spotted the bug in the Bitcoin Cash ABC chain and exploited it after the hard fork, in a bid to cause confusion and chaos.

“The hacker just had to broadcast transactions that met the mempool; validity conditions but failed consensus checks. When miners then attempted to produce blocks with these transactions, they failed. Rather than not making any blocks at all, as a fail-safe, miners appear to have made empty blocks, at least in most of the cases.”

Asymmetric Chainsplit

Due to the uncertainty brought about by the empty blocks, the pre-hard fork Bitcoin ABC 0.18.2 node received a new block, 582,680, a strong indication that some miners may have reverted to the old client, “thinking that the longer chain was in distress and may revert back to before the hardfork.”

The Coordinated Two Block Re-organization

Per the researchers, a few blocks after the hard fork went live, a blockchain re-organization of length two took place on the hard fork side of the split.

Out of the 137 transactions contained in the orphaned block 582,698, only 111 made it into the winning chain; therefore, a two-block double spend appears to have occurred concerning 25 transactions.

In conclusion, the researchers have argued that the Bitcoin Cash team could have prevented the ugly incident if they had planned and coordinated the hard fork more carefully, made efforts to be more transparent and communicated the issues better.