Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
Bitcoin Gold (BTG) was 51% attacked

Bitcoin Gold (BTG) was 51% attacked

Preamble

Bitcoin Gold is a Bitcoin hard-fork that aims to be GPU-mineable by using the Equihash algorithm with parameters (144, 5) also known as "Zhash". The Bitcoin Gold website claims Zhash "uses more memory than an ASIC can muster, but runs fine on many graphics cards". Bitcoin Gold was previously 51% attacked in May 2018 when it was estimated that up to $18 million worth of BTG was double-spent.

The Attacks

Between Thursday and Friday we detected two deep reorgs on BTG, both of which contained double-spends. Their details are listed below. All times are GMT.

In both cases the attacker blocks were mined with the address GWrW5dTZf5XwGWoJuqRKdzkzZFkwtWSqaP in the coinbase transaction. We note that at the time of the attack, on Binance deposits of BTG were credited to one's account for trading after six confirmations, and were available for withdrawals after twelve confirmations. A fourteen or fifteen block reorg would thus evade both of Binance's escrow periods. Binance has since increased their withdrawal requirement for BTG to twenty confirmations. Based on Nicehash market price data for Zhash we estimate the cost of generating each reorg at around 0.2 BTC (~$1,700) and the attacker would have recouped around the same value in block rewards. Therefore, it is possible that the attacks were profitable if the double-spends succeeded at defrauding the attacker's counterparty, or break-even if the double-spends were unsuccessful. This suggests that a confirmation requirement on the order of tens of blocks for BTG is still far too few to make the budget constraint to launch an attack significant.

@MentalNomad

This comment has been minimized.

Copy link

@MentalNomad MentalNomad commented Jan 25, 2020

I didn't have time to thank you earlier - so, thanks for the work and contribution of information.

Note, this part has an error:

1,900 BTG originally sent to GgmzUSgXrXpDxiY34bG6SxaDVi2rQ1zU8Q in TXID 3a17157994502a749a1827883a670d822f8ee95dae94064631770faeec1e8443 was redirected to GgmzUSgXrXpDxiY34bG6SxaDVi2rQ1zU8Q in TXID 6e05e8253b2ce7f1acf6f0684898e13141c0e9b893e1a5e44d215d8ebe4d28b4.

Should read:

1,900 BTG originally sent to GgmzUSgXrXpDxiY34bG6SxaDVi2rQ1zU8Q in TXID 3a17157994502a749a1827883a670d822f8ee95dae94064631770faeec1e8443 was redirected to GNH5cUEg5LZZP5HfLgaLvTE9ApKAf76aBf in TXID 6e05e8253b2ce7f1acf6f0684898e13141c0e9b893e1a5e44d215d8ebe4d28b4.

@metalicjames

This comment has been minimized.

Copy link
Owner Author

@metalicjames metalicjames commented Jan 25, 2020

@MentalNomad indeed, it has been fixed! Thanks!

@hesido

This comment has been minimized.

Copy link

@hesido hesido commented Jan 25, 2020

Exchanges need to dynamically set number of confirmations required based on order book depth and network difficulty.

@MentalNomad

This comment has been minimized.

Copy link

@MentalNomad MentalNomad commented Jan 26, 2020

@mjamin

This comment has been minimized.

Copy link

@mjamin mjamin commented Jan 26, 2020

Exchanges need to dynamically set number of confirmations required based on order book depth and network difficulty.

Here's another idea: stop this pointless exercise. Whatever rules you tack on and workarounds you implement, Bitcoin Gold/Cash/SV/Diamond/etc. will always be fragile and never worthwhile. You will only make people lose money, either through the market or attacks like this.

@rohenaz

This comment has been minimized.

Copy link

@rohenaz rohenaz commented Jan 26, 2020

Exchanges need to dynamically set number of confirmations required based on order book depth and network difficulty.

Here's another idea: stop this pointless exercise. Whatever rules you tack on and workarounds you implement, Bitcoin Gold/Cash/SV/Diamond/etc. will always be fragile and never worthwhile. You will only make people lose money, either through the market or attacks like this.

You're conflating Gold/Diamon (airdrops with different POW) with valid forks stemming from contentious protocol changes (Cash/SV).

@mjamin

This comment has been minimized.

Copy link

@mjamin mjamin commented Jan 26, 2020

You're conflating Gold/Diamon (airdrops with different POW) with valid forks stemming from contentious protocol changes (Cash/SV).

An utterly meaningless distinction.

@mpapec

This comment has been minimized.

Copy link

@mpapec mpapec commented Jan 26, 2020

You're conflating Gold/Diamon (airdrops with different POW) with valid forks stemming from contentious protocol changes (Cash/SV).

An utterly meaningless distinction.

Attackers may actually use risk/reward assessment before picking a target, so there could also be a reason why bgold has horrible record so far, while others do not.

@buralux

This comment has been minimized.

Copy link

@buralux buralux commented Jan 27, 2020

That’s a second attack, don’t understand what do you waiting to protect yourself with Komodo’s delayed Proof of Work (dPoW)???

@hesido

This comment has been minimized.

Copy link

@hesido hesido commented Jan 27, 2020

Exchanges need to dynamically set number of confirmations required based on order book depth and network difficulty.

Here's another idea: stop this pointless exercise. Whatever rules you tack on and workarounds you implement, Bitcoin Gold/Cash/SV/Diamond/etc. will always be fragile and never worthwhile. You will only make people lose money, either through the market or attacks like this.

The idea is valid for any PoW coin. There are a lot of vulnerable coins in the same way. Order book depth / Incoming total deposits at any given time / network difficulty based confirmation requirements can be determined for any coin, and it protects the exchange and the customers. If you have a statistical model to decide which coins are not worth the time, you also have a statistical model to prevent these attacks by dynamically adjusting confirmation requirements.

@mjamin

This comment has been minimized.

Copy link

@mjamin mjamin commented Jan 27, 2020

Forking off from bitcoin is either economically motivated (read: scam), or at best a vote of no confidence in the current development process. So far, any such vote ended in a landslide victory for bitcoin developers (for good reason).

Starting a coin from scratch is also either economically motivated (read: scam), or at best technologically justified. As in: building something that's fundamentally better than bitcoin. If it's the latter, projects borrowing 99% of bitcoin's codebases should immediately raise a red flag. Also, most of the time these kinds of projects are trying to get rid of PoW as their main selling point.

So yes, the idea is valid for any PoW coin that tries to compete with BTC: they're a waste of everyone's time and money.

@Cryptobeetle

This comment has been minimized.

Copy link

@Cryptobeetle Cryptobeetle commented Jan 27, 2020

I think the solution to the “51% attack” problem can be found in this thread: https://bitcointalk.org/index.php?topic=5215111.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.