Bitcoin Gold 51% Attacked, $18 Million Stolen Through Double Spends – Trustnodes

Bitcoin Gold 51% Attacked, $18 Million Stolen Through Double Spends


Bitcoin Gold has become the biggest public blockchain to experience a 51% attack with 388,201 BTG stolen, amounting to some $17.8 million at the current price.

The attack was first announced on the 18th of May 2018 by Ed Iskra from the Bitcoin Gold team. In a public post, he said:

“An unknown party with access to very large amounts of hashpower is trying to use “51% attacks” to perform “double spend” attacks to steal money from Exchanges. We have been advising all exchanges to increase confirmations and carefully review large deposits…

A party like an Exchange may accept large deposits automatically, allow the user to trade into a different coin quickly, and then withdraw automatically. This is why they are targeting Exchanges…

One of the targeted Exchanges reported that they strongly believe this attacker attempted to hit them with a double-spend of BTC in the past. In their words, ‘we are 100% sure that it is the same person, we found many associations between the accounts.'”

The only known double spend in bitcoin was around 2014 by a rogue employee within the then biggest btc mining pool, Ghash, which lasted very briefly.

In Bitcoin Gold this very recent attack was far bigger in scale, with a Bitcoin Gold core developer publicly stating:

“The amounts of the observed double spending transactions are from ~8000 BTG to ~12000 BTG. So each time the attacker succeeds, the exchanges lose that amount.”

They have tracked the hacker’s address, which currently shows it has received 388,201 BTG. They apparently sent the total network hashrate to 175MH from a usual 40 MH. Suggesting the hacker had some significant hashrate, with his block times being between 100 and 160 seconds apart, or around 2.5 minutes.

Confirmed double spends of Bitcoin Gold.

This vulnerability has not been addressed as far as we are aware so the attacker may return at any point, but confirmation times requirements in BTG have now probably been increased significantly, and he/she or they now probably have enough money.

The underlying vulnerability is probably the fact BTG shares the same proof of work algorithm as a bigger coin, Zcash, with BTG currently at a market cap of $800 million, while Zcash stands at $1.1 billion.

Estimates suggest it takes about $200,000 a day to 51% attack BTG, and around as much to 51% attack ETC which likewise shares the same mining algorithm as a far bigger coin, Ethereum.

This re-evaluated estimate is due to this shared algorithm, allowing one to rent hashpower rather than going out and buying actual hardware.

Ethereum like Proof of Stake and the finalizing checkpoints it provides can make such attacks a lot more difficult, as can to some extent the usage of different algos so that one doesn’t share miners.

The question is, however, why did this attack stop? One reason presumably is because this is theft, as in the exchange is lied to and stolen from, so the attacker might think it better to honestly use that hashrate and so actually freely move or exchange the coins while not losing sleep or risking prison.

Another reasons might be that the estimates have flawed assumptions which leads to the attack not being as profitable as one might think. Yet probably the main reason is because of this increased confirmations requirements making the attack a lot more difficult to perform.

The attack in question is basically rolling back the blockchain. The hacker mines in private a chain from a certain block, then publishes it at a point, with 22 blocks deep the highest seen in the BTG case.

All those 22 blocks that have been mined by other miners in effect vanish, with everyone now mining on top of the hacker’s blocks.

That means during this period what one might think was a confirmed transaction, may become an unconfirmed transaction. Something which could cause quite a bit of chaos because if you sent your BTG to an exchange, you might now also have them in your own wallet.

That’s the point of it, as far as the attacker is concerned. Because now he can send the coins to another exchange and so repeat the process of having them show in his own wallet again.

His coins, not anyone else’s. As stated others might share the same experience, but for their coins only. Because the only thing that is being double spent here is one’s own coins. The coins of everyone else are safe.

Well, during the attacking period ownership might change, say if A sent you coins then they might vanish from your wallet and show up in A’s wallet again, so transacting during this period or accepting coins while a 51% attack is ongoing is very unsafe.

The point we are trying to put across however is that those vanishing coins do not go to the attacker, unless it was his own coins. Basically, a 51% attack is reverting back time, or going back in time or history.

One therefore should not be transacting during that period and the best initial way to defend from such attacks is to sound the alarm bell as quickly as possible to let everyone know of it so that all stop accepting transactions preferably completely or if they must then not without 100, 1,000 or a trillion confirmations as your/their risk appetite might be.

Once/while all are alert the second line of defense is to quickly get out a new client with a new and different Proof of Work algorithm and do so preferably within hours, which means it should have been ready to go before hand by it all being coded when the sun shines.

Updating the network in these sort of circumstances would be a pretty quick affair, you would think, perhaps within hours. The key players in this instance would not be miners, but exchanges and businesses. Once they update to the new node, that new node in effect becomes the network assuming all others agree as you would think would be the case in such instances.

The best line of defense however would be for it to never get to such a situation. That would be the case if one is using their own algo, thus does not share miners, and if one has sufficient hardware backing your chain so making it difficult for others to externally attack.

We haven’t seen any internal intentional 51% attacks, but it does sometime accidentally happen. In bitcoin it has occurred about twice if we are not mistaken in or around 2013 and in 2015. The latter occurred because one miner had forgotten to update one node, unintentionally creating two different chains.

The end results are the same, but of course an accidental split and an intentional attacking split are quite different in nature as in the case of the former it was resolved within hours without anyone really caring. While in the case of the latter one can’t really place much trust on the chain until it does address the vulnerability.

While for ethereum we haven’t really seen any such accidental or intentional attacking splits at all, but of course there was the intentional amicable split in 2016 when a new network, ETC, was willfully created.

In regards to those latter splits, or in the case of bitcoin the split to bitcoin cash, there is nothing you can do nor does anyone really care because it does not affect the network in any way whatever.

Attacking splits, however, should not be occurring in a network with a significant market cap of $1 billion, but it did because they share the algo so a new understanding now needs to arise that algo sharing creates an insecure chain.

A final point to make is that Ethereum’s Casper FFG Proof of Stake layer on top of Proof of Work should make such splits far more difficult, and thus the chain more secure, as you’d need to own 51% of the coins to attack, which makes it very much pointless because you’d be losing all that 51% wealth if one can even get it.

So this Bitcoin Gold matter is localized to their own coin, and perhaps other secondary coins which share algos, with other primary chains being quite safe as they haven’t seen such attacks in nearly a decade now, suggesting it wouldn’t work.

This shared algo vulnerability has actually been known for quite some time with Luke-Jr, a Bitcoin Core developer and a Blockstream employee, performing a 51% attack on a coin that shared an algo some six years ago or so in or around 2012.

Collectively, however, we clearly have forgotten about it, until now, so the BTG events need to be closely studied with the right lessons and conclusions taken from it.



Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>