The Bitcoin Cash fiasco: a reorg or a 51 percent attack?

Like all blockchain projects, Bitcoin Cash (BCH) schedules regular system upgrades as part of its long-term plan to uphold security, support scaling solutions, and fix any bugs in the software. The May 15 upgrade was one such planned update. It was designed to introduce two main features into the Bitcoin Cash network code.

The background

The first of these features was Schnorr signatures, a type of cryptographic signature system developed by Claus Schnorr. The Schnorr algorithm is able to support increased privacy as well as multi-signature capabilities. These aspects contribute to the long term scaling solutions on the BCH roadmap.

The second feature of the May 15 upgrade caused most of the controversy that occurred following its implementation. This is the SegWit recovery feature, which was designed to allow users to recoup any BCH that were erroneously sent to SegWit addresses. Prior to this update, these funds were considered lost as SegWit addresses are valid on the BTC network but not on the BCH network. However, because of the many similarities between the two networks, a number of users had lost BCH by sending the funds to invalid SegWit addresses where they now lay unspendable.

However, following the May 15 upgrade, these previously unspendable coins became spendable under certain circumstances. Through the upgrade, the BCH network modified the clean stack rule. The first requirement to access BCH held on SegWit addresses is knowledge of the hash of the public key associated with its corresponding SegWit address to spend the funds on the BCH network.

The owner of the address has knowledge of the hash public key or the unlocking script associated with their SegWit address. However, it is possible for a third party to acquire this information because the hash is revealed when a SegWit address sends funds. In this way, if a SegWit address holds BCH funds but has also sent and received BTC on the Bitcoin network, it is possible to discover the hash through relatively simple blockchain analysis. Thus, any party with sophisticated knowledge of blockchain programming would be able to claim the unspendable BCH funds in SegWit addresses.

The second requirement necessary to spend the BCH funds under the May 15 upgrade was miner agreement due to the fact that the transactions that spend the BCH held in SegWit address are designated as “nonstandard transactions.” This designation simply means that while they are valid transactions, they will not propagate across the network, because network nodes refuse to relay nonstandard transactions.

Following the May 15 upgrade, it was possible for any party to claim the BCH held in SegWit addresses as long as they met the above-mentioned stipulations. This became the crux of the matter as miners raced to recoup these funds.

The power struggle

Once the upgrade came into effect in the BCH network on May 15, it became apparent that there was a bug in the code of the Bitcoin ABC software. Bitcoin ABC is the most popular implementation of the Bitcoin Cash software. The bug was unrelated to the BCH system update but affected many miners as they were unable to include transactions in the blocks mined after the upgrade. The empty blocks caused a large number of unconfirmed transactions to be held in the mempool.

Shortly after, however, ABC upgraded its code, allowing many miners to resume their activities as usual. According to research published by Coinbase, at this juncture “two blocks 582698 and 582699 were mined by two separate miners identified by ‘unknown’ and ‘Prohashing’ strings in the respective blocks’ coinbase transactions.” Block 582698 was mined by the ‘unknown’ miner and in it were transactions that spent BCH from more than 1000 SegWit addresses.

However, at 9:10 am PT, a 2-block deep chain reorganization was observed on the BCH network. The blocks mined by ProHashing and the ‘unknown’ miner were orphaned by a longer chain mined by BTC.top and BTC.com. The duo of larger miners added four blocks to the network in comparison to the two blocks by the opposite duo smaller miners.

In the blocks that followed, up until block 582715, a number of double spend transactions occurred. There were 29 in number amounting to a total of 3,796 BCH. One which occurred in block 582701 (4 BCH), does not seem to be related to SegWit recovery. 1,278 were contained in block 582705 (3,655 BCH), which distributed the BCH held in the SegWit addresses to the valid equivalent BCH addresses. Lastly, there were 13 in block 582715 (216 BCH) which sent the BCH held in the SegWit addresses to BCH addresses which did not correspond with the SegWit addresses. These BCH addresses were likely controlled by the unknown miner.

The controversy

The reorganization of the BCH blockchain was motivated by the need to redistribute the funds locked in the SegWit addresses to the corresponding BCH addresses. The first party, known as the unknown miner, took advantage of the requirements for the SegWit Recovery upgrade to claim the BCH for himself. However, the efforts of BTC.top and BTC.com thwarted his plans as they colluded to use their superior hash power in order to create the longest chain and thus return the majority of the funds to their respective owners.

Unsurprisingly, this course of action attracted debate as it highlighted a lack of decentralization in the BCH network.

Proponents argue that this was the altruistic and moral course of action as the unknown miner was effectively stealing funds that did not belong to him. Opponents, however, believe the decision threatens the security of the BCH blockchain as it creates a situation where miners can collude to produce the version of history they are in favor of.

The debate is encapsulated in the wording used by the opposing parties. Proponents are calling it a reorganization because it went only two blocks deep and was not hostile in nature. However, opponents are calling it a 51 percent attack because two parties who are meant to be independent came together to change the blockchain.

Ultimately, it raises questions about blockchain finality, centralization, and immutability. Crypto-economics are centered on game theory, the idea that rational humans will act in their own self-interest. Blockchains use this to their advantage. However, we have witnessed a number of occasions when humans have intervened in the workings of blockchains, such as after the DAO hack, to turn back time and break the immutability of the chain.

In this case, and that of the DAO hack, there are users who were happy with this course of action, as was much of the community. However, in cases like the recent suggestion by Binance CEO, Changpeng Zhao, to orphan certain blocks to recoup stolen funds (following the Binance hack) on the Bitcoin blockchain, the community was vehemently opposed.

One Redditor encapsulates the situation stating: “They have turned it into a social problem rather than a mathematical problem which is exactly what Bitcoin tries to get away from and it does that to make it socially scalable. One party and another do not have to have the same perspective or the same subjective idea of who the good guy or the bad guy is, verify don’t trust.”

The question is whether blockchains should be allowed to continue with the version of events first recorded, whether they are legal, moral or altruistic, or whether the community through the miners should intervene when they see fit. While this is, of course, a generalization, this is how the two opposing camps see the issue. It is a complex debate because blockchains are designed to be immutable, after achieving finality, while miners are able to reorg blockchains before a certain block depth. Therefore, depending on your standpoint, it is either a 51 percent attack or a simple reorganization.