2 Bitcoin Cash Mining Pools Organized 51% Attack to Thwart Hacker

by Rachel McIntosh
  • A malicious miner attempting to exploit a vulnerability on BCH was stopped by miners who exploited a different vulnerability.
2 Bitcoin Cash Mining Pools Organized 51% Attack to Thwart Hacker
FM

A malicious miner on the BCH network attempted to steal over $1.35 million through exploiting a vulnerability on the network. However, other miners on the network seemed to have quickly organized themselves to exploit another vulnerability on the network in order to prevent the malicious miner from being successful.

Here's what happened. (You really can't make this stuff up.)

Bitcoin Cash’s most recent hard fork seems to have resulted in a “double spend” attack of over $1.35 million, according to a new report by BitMex Research published on May 24th.

In other words, BCH’s most recent software update may have resulted in $1.35 million in duplicate transactions. A “double spend” is what happens when the same digital coins are spent more than one time.

Following the fork, a total of 25 transactions involving 3392 BCH were not included in the reorganized chain, meaning that those 3392 BCH could have ultimately remained in an attacker’s control.

However, per the report, “the only victim with respect to these double spent coins could have been the original ‘thief’”--two mining pools (BTC.com and BTC.top) that controlled more than half of the BCH network carried out a “51 percent attack” to reverse the attacker’s transactions.

While the mining pools’ actions may have ultimately been a good thing for the BCH community, the move has caused some controversy--after all, the fact that these two pools were able to orchestrate the attack reveals that the BCH network is perhaps more centralized than most of its users knew.

“To coordinate a reorg to revert unknown’s transactions,” wrote Bitcoin Cash developer Kiarahpromises in a blog post. “This is a 51% Attack . The absolutely worst attack possible. It’s there in the whitepaper. What about (miner and developer) decentralized and uncensorable cash? Only when convenient?”

“This is a very unfortunate situation, but it is also what proof of work actually is,” wrote Bitcoin Cash supporter Jonathan Silverblood in response. “The miners in this case did choose to drop prohashes block and from what I heard, it is because they deemed a transaction within it to have been invalid.”

What Caused the Attack?

According to BitMex’ report, the double spend appears to have been caused by three factors. The most significant of these appears to have been an attacker that discovered and exploited a vulnerability in BCH’s protocol right after the fork occurred. The attacker was able to “broadcast transactions which met the mempool validity conditions but failed the consensus checks.”

In other words, “since the original split in 2017, there has been a significant number of coins accidentally sent to ‘anyone can spend’ addresses (due to [transaction] compatibility of sigs, but no #SegWit on #BCH), or possibly they’ve been replayed from #Bitcoin onto the #BCH network,” explained bitcoin podcast host Guy Swann on Twitter.

The attacker in this situation was a miner who realized that these coins were up for grabs.

However, when the miner attempted to take the coins for themselves, “[BTC.top and BTC.com] saw & immediately decided to re-organize and remove these [transactions], in favor of their own [transactions], spending the same P2SH coins, [and] many others.”

Swann theorized that the two mining pools must have been communicating with one another privately throughout the fork, ready to act quickly if something went wrong.

“Looks like they were prepared during the fork, & watching closely to recover the #SegWit coins themselves,” he wrote. “Rumor is (& possibly the only thing that makes sense) that they were communicating privately the entire time during the fork.”

A malicious miner on the BCH network attempted to steal over $1.35 million through exploiting a vulnerability on the network. However, other miners on the network seemed to have quickly organized themselves to exploit another vulnerability on the network in order to prevent the malicious miner from being successful.

Here's what happened. (You really can't make this stuff up.)

Bitcoin Cash’s most recent hard fork seems to have resulted in a “double spend” attack of over $1.35 million, according to a new report by BitMex Research published on May 24th.

In other words, BCH’s most recent software update may have resulted in $1.35 million in duplicate transactions. A “double spend” is what happens when the same digital coins are spent more than one time.

Following the fork, a total of 25 transactions involving 3392 BCH were not included in the reorganized chain, meaning that those 3392 BCH could have ultimately remained in an attacker’s control.

However, per the report, “the only victim with respect to these double spent coins could have been the original ‘thief’”--two mining pools (BTC.com and BTC.top) that controlled more than half of the BCH network carried out a “51 percent attack” to reverse the attacker’s transactions.

While the mining pools’ actions may have ultimately been a good thing for the BCH community, the move has caused some controversy--after all, the fact that these two pools were able to orchestrate the attack reveals that the BCH network is perhaps more centralized than most of its users knew.

“To coordinate a reorg to revert unknown’s transactions,” wrote Bitcoin Cash developer Kiarahpromises in a blog post. “This is a 51% Attack . The absolutely worst attack possible. It’s there in the whitepaper. What about (miner and developer) decentralized and uncensorable cash? Only when convenient?”

“This is a very unfortunate situation, but it is also what proof of work actually is,” wrote Bitcoin Cash supporter Jonathan Silverblood in response. “The miners in this case did choose to drop prohashes block and from what I heard, it is because they deemed a transaction within it to have been invalid.”

What Caused the Attack?

According to BitMex’ report, the double spend appears to have been caused by three factors. The most significant of these appears to have been an attacker that discovered and exploited a vulnerability in BCH’s protocol right after the fork occurred. The attacker was able to “broadcast transactions which met the mempool validity conditions but failed the consensus checks.”

In other words, “since the original split in 2017, there has been a significant number of coins accidentally sent to ‘anyone can spend’ addresses (due to [transaction] compatibility of sigs, but no #SegWit on #BCH), or possibly they’ve been replayed from #Bitcoin onto the #BCH network,” explained bitcoin podcast host Guy Swann on Twitter.

The attacker in this situation was a miner who realized that these coins were up for grabs.

However, when the miner attempted to take the coins for themselves, “[BTC.top and BTC.com] saw & immediately decided to re-organize and remove these [transactions], in favor of their own [transactions], spending the same P2SH coins, [and] many others.”

Swann theorized that the two mining pools must have been communicating with one another privately throughout the fork, ready to act quickly if something went wrong.

“Looks like they were prepared during the fork, & watching closely to recover the #SegWit coins themselves,” he wrote. “Rumor is (& possibly the only thing that makes sense) that they were communicating privately the entire time during the fork.”

About the Author: Rachel McIntosh
Rachel McIntosh
  • 1509 Articles
  • 52 Followers
About the Author: Rachel McIntosh
Rachel is a self-taught crypto geek and a passionate writer. She believes in the power that the written word has to educate, connect and empower individuals to make positive and powerful financial choices. She is the Podcast Host and a Cryptocurrency Editor at Finance Magnates.
  • 1509 Articles
  • 52 Followers

More from the Author

CryptoCurrency

!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|} !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}