The development team behind Bitcoin Gold has released an update on last week’s 51 percent attack, which the attacker weaponized through a double spend attack to steal funds from cryptocurrency exchanges.
Published on Thursday, the update confirmed that the attacker had gained majority control of the network’s hashrate and used that control to reorganize the blockchain and reverse transactions.
In this case, the attacker made deposits at cryptocurrency exchanges, traded the coins for BTC or another coin, and then withdrew the funds. Next, the attacker used their dominant computing power to force the rest of the network to accept falsified blocks that reversed their initial deposits and caused these funds to vanish from exchange-controlled wallets.
As CCN reported, an address associated with the attacker had sent itself more than 380,000 BTG in a series of transactions consistent with double spending behavior. It’s not clear how many of these transactions resulted in successful thefts from exchanges. In theory, the attacker could have made off with more than $18 million worth of funds, but only if every transaction resulted in a successful theft (again, the attacker’s rate of success has not been verified).
The project’s developers blamed the attack in part on the fact that bitcoin gold’s mining algorithm — Equihash — is used by a number of other cryptocurrencies, rendering the pool of available hashpower much larger than the bitcoin gold network’s individual hashpower.
Bitcoin Gold had already planned to move to a new algorithm, a decision the community made after mining hardware manufacturer Bitmain announced that it was accepting preorders for the first Equihash ASIC miner, and the developers said that moving to this new algorithm will render the network “dramatically safer” from future 51 percent attacks.
They said that, particularly in the wake of the recent successful attack, they will deploy the new algorithm as quickly as possible:
“We’ve been working at an incredible pace the past days to put the plan and pieces together, and we expect to upgrade our mainnet approximately seven days after the necessary software is up and running on our testnet.”
“While it would be better to give all our partners more than seven days to test and deploy to avoid disruption, these attacks have already forced disruption on us all, so we feel it’s best to get the upgrade completed as soon as we possibly can,” they concluded.