Bitcoin Cash ABC Miners Did Not “Take Over” the Protocol
For some reason, CoinDesk and other publications have taken to publishing the narrative that Bitcoin Cash leveled a “51% attack” on its own chain.
Here is one of the articles in question for reference.
It is alleged that two mining pools (BTC.com and BTC.top) both carried out the ‘attack’ in concert in order to prevent the Bitcoin Cash chain from being further compromised.
On May 15th, Bitcoin Cash’s blockchain was set to activate its planned hard fork (not contentious, so there was not supposed to be a split on the network).
Shortly after the fork, many individuals noticed that the Bitcoin Cash mempool was beginning to fill up at a rapid rate and that the blocks that were being subsequently produced after the fork were largely empty.
Below are some screenshots that were taken by the author at the time of the incident:
Reasons For the Chaos
Reason #1 — Invalid Transaction Exploit
As stated in a few sources, there was a transaction exploit that led to the mempool being flooded with transactions that would be considered invalid by the protocol.
This was first noted by ABC dev and miner, ‘checksum0’ as well as a developer for Bitcoin Verde.
The latter posted a thread on Reddit, which detailed the event and the events that had transpired since:
Specifically, the developer stated that:
The link to this patch can be found here:
The change is reflected in the picture below as well:
Another, more thorough, explanation of the entire situation was provided later that same day by another Bitcoin Verde developer.
Dissecting the Amended, Full Explanation of the Situation
The logic in the post is fairly easy to follow and backed up by precedent (which we’ll get into in this piece).
The first two points in the post are simple enough to comprehend. They simply discuss the process by which ‘sigOps’ are counted in transactions on the BCH protocol.
In ‘2a’, the author notes that the number of ‘sigOps’ that are allowed in a particular block are limited in order to protect the safety of the chain.
Specifically, the author states that,
Specifically, developers talked about a potential transaction that could take at least 3 minutes to verify.
This potential exploit is also filed in the Bitcoin Wiki under CVE-2013–2292.
This common vulnerability precludes the use of excessive sigOPs, but the thread does note how this would be an additional vulnerability factor for the issue in question if such a limit (200) for sigOP inclusion were not placed within the protocol.
The Actual Issue
Going back to the Reddit thread, authored by the Verde developer, the actual attack is detailed in full in the next portion where the author states,
- Transactions that would not (and should not) be considered valid on the actual blockchain, were considered valid in mempools.
- Because of this, this caused miners to construct blocks that had those faulty transactions as part of their ‘candidate block’ formation.
- However, once the mining module that these miners use re-validated the transactions in the block, it was discovered that there were too many sigOPs for the transactions in the block to be considered valid.
- This led the software to simply mine an empty block rather than pick through the mempool for transactions that would be considered valid.
- These empty blocks, however, contained ‘1 transaction’ because that 1 transaction was the ‘Coinbase reward’ (12.5 $BCH).
Addressing the Forking Concerns
The first thing to address with the entire issue is that this was not a problem that had to do with the upgrade itself. For some reason, this was reported by outlets such as ‘BitMex Research’:
It appears as if there may be a problem with the Bitcoin Cash hardfork upgrade, the number of txs per block is low (0 in the last 9 blocks, other than the coinbase txn). Our mempool has 1622 txs
Below chart is number of txs per block and the orange line is the hardfork point pic.twitter.com/UR3jQuN6Zm
— BitMEX Research (@BitMEXResearch) May 15, 2019
The transaction issue was an attack vector that was exploited at the time of the hard fork (more than likely to cause confusion such as what was created at the time of the attack).
However, one thing that BitMex Research did get right about this fork split was the following tweet:
Bitcoin Cash – The hardfork and all the events summarized in one picture
In the below image we have attempted to illustrate all the relevant events:
* The hardfork
* A chainsplit (With asymmetric validity conditions)
* A bug causing empty blocks
* A non-consensus re-org pic.twitter.com/RX3V29nyMQ
— BitMEX Research (@BitMEXResearch) May 15, 2019
Bitcoin Cash was not “51% attacked”, rather more than 51% of the hashing power decided to mine on the chain with the amended transaction validation rules that also did not include the block that was mined by the malicious miner.
Remember, this includes accounting for the incidence of ‘CHECKDATASIG’ in the mempool rather than excluding this measure in the mempool.
As noted above by BitMex, there were chain splits. There was one that was caused by nodes simply not upgrading. That is irrelevant to this greater discussion.
Orphaned Block That’s Been Labeled as a ‘51% Attack’
There was another, subsequent, chain split, however, that was caused when BTC.top and BTC.com decided to mine on the last ‘honest’ block. Unfortunately, it appears that ‘Prohashing’ (the mining pool that mined a valid block on top of the attacker’s block) was not aware of such a decision to mine on the last block produced by an honest individual in the network and they subsequently created a block on top of the attacker’s block, which was eventually ‘orphaned’.
In the bottom where it states, ‘Non consensus re-org’, that is referring to the consolidated blockchain that was created after the attacker’s block and the ‘Prohashing’ block were both orphaned.
It must be noted also that this was not a case where a mere 51% of all hash power was allocated to mining on top of the last honest block. Rather, this was a collected effort by the ABC developers as well as the large mining pools we’ve discussed (BTC.top & BTC.com).
Addressing the Segregated Witness Coins That Were ‘Stolen’
This is probably the lengthiest (and most confusing) aspect of the entire ordeal to explain to those that are not entirely familiar with how the Bitcoin Cash (or Bitcoin) protocol works. But we’re going to dissect this in a workable manner that provides the appropriate information for those that are not in the ‘know’ on this.
For starters, it should be known that…
The Bitcoin Cash Segregated Witness Transactions Were a Separate Issue
Segregated Witness is not technically enabled on the Bitcoin Cash protocol, but these transactions can be sent, technically.
However, they are regarded by nodes on the network in the same way that nodes that have failed to upgrade on Bitcoin will regard such transactions.
Thus, while this is a non-standard transaction that nearly all pools and miners will generally not accept (which means it will be orphaned), it can still be pushed as a valid transaction.
Well-known developer, ‘Murch’ affirmed this (as well as the properties of SegWit) in a response on Bitcoin’s ‘Stackexchange’ website in 2017.
Specifically, he stated:
How ‘SegWit’ Coins are ‘Stealable’ on the Bitcoin Cash Chain
When $BCH split, there were a number of individuals that had sent the funds to Segregated Witness outputs, making them effectively unspendable from that point.
This is because no miners or nodes will generally accept such transactions. However, due to the fact that these transactions are seen as ‘anyone-can-spend’ transactions by non-upgraded nodes and miners (the entire $BCH network is technically not ‘upgraded’), these transactions can technically be considered valid if mined in a block.
The only issue is actually having these transactions mined into a block. However, this is far from impossible because it happened during the hard fork debacle on May 15th, 2019, and it also happened over a year ago on the protocol.
Most notably, the actor that moved these funds was offering a ‘recovery’ service where they taxed 30% of the total fund value for the service of returning these funds to their rightful owners.
That thread can be found here.
How SegWit Relates to the Bitcoin Cash Incident on May 15th
It is important to note that this incident is entirely separate from the ‘poisonous transactions’ attack that was leveraged on the protocol.
Many speculate that the two attacks were meant to be done in tandem (indeed, had the ‘poisonous transactions’ attack lasted for a longer period of time, this may have been the case).
What Actually Happened
After the fix was put in place, a bad actor on the Bitcoin Cash chain spent several of the “locked” SegWit funds on the $BCH protocol (moving them to either wallets they controlled or to other connected individuals).
Seeing this, BTC.top and BTC.com (the two noted mining pools in this situation) decided to build from a different block height, deciding to instead spend the SegWit transactions that the attacker had spent (remember, miners can spend this transaction because there are no upgraded nodes on the $BCH protocol, so these are ‘anyone-can-spend’ funds) and send them back to p2pkh addresses that had the equivalent public keys.
Because (compressed) P2PKH keys are necessary preceding forms of P2WPKH (SegWit) addresses.
Therefore, the transactions being re-spent by BTC.top to the corresponding P2PKH keys are what allowed the overall funds to be spendable again.
Visualizing This Entire Situation
The following is a more accurate representation of what happened during this entire escapade:
This situation is far from a 51% attack, however, because it is more than obvious that the network had zero intentions of building on top of the attacker’s block where they had illicitly spent SW transactions that did not belong to them.
This should be taken into consideration when using the following article as a source of ‘information’ about the hack: https://honest.cash/kiarahpromise/sigop-counting-4528
This article and its subsequent explanation gained a significant amount of traction on social media over the past 24–48 hours for some reason.
The contents of the article were blasted even further when a thread on Twitter by a user named ‘TheCryptoconomy’ blasted its contents and perpetuated the inaccurate story that there was a ‘takeover’ on the Bitcoin Cash protocol when this, in fact, is not what happened:
1/ What I've gathered from loose details:
First, there was an unintentional split with the recent #BCH "upgrade."
— Guy Swann ⚡[Pay me in Bitcoin] (@TheCryptoconomy) May 24, 2019
Reality of the Situation
The actions that were taken by BTC.com and BTC.top represented actions that the entire Bitcoin Cash community was on board with. It is true that developers did contact the major miners on the protocol to coordinate a solution.
Before critics are quit to blast Bitcoin Cash for taking this action, they must remember that the same thing has happened on Bitcoin Core more than once.
For example, when there was an overflow error on the protocol in 2010 while Satoshi was still active, a hard fork was implemented to amend the situation. This, of course, would not have been possible had it not been for great coordination between the developers and miners (which were virtually synonymous at that point in time).
There are other similar situations, such as the protocol split in 2013 after a hard fork that forced developers to coordinate with miners on the Bitcoin protocol to ensure that a proper resolution was formed.