By CCN: An attempted disruption of the Bitcoin Cash blockchain resulted in a negative outcome for the attacker. A BCH tinkerer with Reddit username NilacTheGrim boasted yesterday that he had “liquidated” the crypto funds belonging to the would-be blockchain bandit.
Weak Address Security Come Back to Bite Bitcoin Cash Attacker
To do so, he found a flaw in the wallet security model used by the attacker, who has not identified himself or been identified at press time.
“The attackers used p2sh addresses that had easily guessable scriptSigs (they lacked a signature altogether to redeem). […] I ended up liquidating about ~1.2BCH of their funds just now […] So you will see the mempool now has lots of tx’s and is 18MB full as of the time of this writing. These tx’s are all the special tx’s that have a lot of sigops that I made to liquidate (take) the attacker’s funds.”
There is no government regulating the interactions on Bitcoin Cash or, for that matter, Bitcoin Cash. People can do whatever is possible within the rules of consensus. As such, Changpeng Zhao’s idea to “reorganize” the Bitcoin blockchain was taken very seriously by people who understand there’s no stopping him – if he has the ability.
Spam of a New Kind
The intent of the initial attack was apparently to disrupt normal operations for Bitcoin Cash. The attacker injected thousands of invalid transactions into the mempool and made it difficult for anyone to make regular transactions. The attack coincided with a scheduled network hard fork.
Notably, BitcoinXT recently dropped off the Bitcoin Cash network, resigning from development efforts in protest of such regularly scheduled hard forks.
The origin of the bug which led to the attack was not immediately clear. Some observers, such as Cornell Professor Emin Gün Sirer, claim the bug was born of the block template code.
BCH came under attack today, due to an old bug in block template creation. Attack led to empty blocks for a short while, until patched, otherwise had little effect.
— Emin Gün Sirer (@el33th4xor) May 15, 2019
Another spectator has a different take on the attack, which makes more sense. It’s possible to submit transactions to the mempool which you know will never make it into blocks.
The reason why @el33th4xor blocks everyone on Twitter, is so his followers can’t see why is wrong.
The bug is in the mempool acceptance code, not the block template code. Essentially the opposite of standardness, so valid mempool transactions are invalid in blocks. pic.twitter.com/FWx9KIGu1o
— Sjors Provoost (@provoost) May 15, 2019
Mining pools reacted to the spam attack by mining empty blocks and forking away from the chain that held them in the mempool (submitted transactions not yet included in blocks).
Some miners were forced to mine empty blocks due to their design, which is explained later.
This new fork gave some the impression that Bitcoin Cash was in a state of flux, with two equally valid blockchains existing. Perhaps a rush to judgment, the conclusion drew ire.
The Bitcoin Cash chain has split into two chains. A hardfork occurred at block 582,679, however since that block, upgraded and non-upgraded nodes have split onto different chains.
The Bitcoin Cash network may not currently be safe for payments https://t.co/U9hbK4peip pic.twitter.com/Yfcnp6G0Dj
— BitMEX Research (@BitMEXResearch) May 15, 2019
582680 is the block height of the upgrade, you know…
You could at least talk about the real problem which is the bug found in Bitcoin ABC, which is why miners are currently mining empty blocks: https://t.co/a2FLzziWBn
— Ludovic Lars (@lugaxker) May 15, 2019
Bitcoin Cash’s Four-Hour Emergency Response
Bitcoin ABC, the dominant development team in Bitcoin Cash, deployed a patch for its nodes within four hours of the initial attack.
Nevertheless, several Twitter users with a dislike of Bitcoin Cash took the opportunity to poke fun, take shots, and generally denigrate the cryptocurrency.
When was it ever safe or even used for payment ?
— CryptoPrecision ⚡️ (@CryptoPrecision) May 15, 2019
A similar attack on Bitcoin would have had a much more significant impact, the limited space of blocks being a primary issue in its functionality. However, the attack would have been much more expensive to conduct. The attack is not currently possible in Bitcoin, as far as we know, but bugs are introduced and patched regularly in open source development.
Origins of a Spam Flood
This particular exploit was the result of code activated last November. A new feature in Bitcoin Cash made it possible, and whoever discovered it opted not to report it but waited until a scheduled hardfork (“upgrade”) to execute an attack. The attacker likely hoped his actions would have a greater disruptive effect on Bitcoin Cash, which leads one to believe they are not a supporter.
Here is a brief explanation of the bug:
“When accepted to the mempool, the transaction is recorded along with its number of sigops.
“[…] During the acceptance of the mempool, the transaction’s scripts are parsed and each occurrence of a sigop is counted. When OP_CHECKDATASIG was introduced during the November upgrade, the procedure that counted the number of sigops needed to know if it should count OP_CHECKDATASIG as a sigop or as nothing (since before November, it was not a signature checking operation). The way the procedure knows what to count is controlled by a “flag” that is passed along with the script. If the flag is included, OP_CHECKDATASIG is counted as a sigop; without it, it is counted as nothing. Last November, every place that counted sigops included the flag EXCEPT the place where they were recorded in the mempool–instead, the flag was omitted and transactions using OP_CHECKDATASIG were logged to the mempool as having no sigops. […]
“The number of sigops for transactions using OP_CHECKDATASIG is recorded as zero–but only during the mempool step, not during any of the other operations. So these OP_CHECKDATASIG transactions can all get grouped up into the same block. The prototype block builder thinks the block should have very few sigops, but the actual block has many, many, sigops. […] However, since the new block has too many sigops included in it, the mining software starts working on an empty block (which is not ideal, but more profitable than leaving thousands of ASICs idle doing nothing). [T]he empty block is mined and transmitted to the network. It is a valid block, but does not contain any other transactions other than the coinbase. Again, this is because the prototype block failed to validate due to having too many sigops.”
If we were to name the attack, we might say “sigop flood attack,” as that is essentially what happened: mining nodes were overloaded with sigop validations, which led them to mine blocks with no valid transactions.
The Bitcoin Cash vigilante discovered a weakness in the addresses used by the attacker. He then conducted a similar move to a “sigop flood” to drain the balance of the attacker’s wallet. The transactions will take days to clear, due to the subsequent patch of the Bitcoin Cash network.
