Reorgs on Bitcoin Gold: Counterattacks in the wild

The economic security of Bitcoin and other proof-of-work cryptocurrencies relies on how expensive it is to rewrite the blockchain. If a 51% attack were economically feasible, an attacker could send a transaction to a victim, launch the attack, and then double spend the same coins back to themselves. Satoshi Nakamoto assumed that this would not occur because a majority of miners would find it more lucrative to honestly follow the protocol than to attack the chain, the source of their own mining revenues.

Recent work has shown the cost of attack on a coin can vary widely. This cost depends on factors like the liquidity of hashrate, the impact on coin price, and the length of the required rewrite; under certain circumstances an attack could even be free. As of March 2020 for chains like Bitcoin, miners make large advance investments in mining equipment and are reluctant to rent any significant fraction of the chain’s hashpower, making the cost today likely quite high. Some coins, however, use proof-of-work algorithms for which there is enough new hashrate for rent to cost-effectively launch 51% attacks, and there have been double-spend attacks on these coins observed in practice. Using hashrate markets like NiceHash, buyers and sellers can easily find each other. It is now commonly believed that low hashrate coins, coins that are not the largest in their proof-of-work algorithm class, and coins for which there is a liquid hashrate rental market are all susceptible to cheap 51% attacks and are insecure.

In a recent paper titled Double-Spend Counterattacks, we discuss a strategy to prevent 51% attacks in vulnerable proof-of-work based coins: the victim can counterattack. We show that the victim’s ability to rent hashrate and mine on the original chain, overtaking the attacker chain in the event of an attack, can deter the attack from happening at all in equilibrium. The results hold under the following assumptions: (1) the victim suffers a moderate reputational cost to losing that the attacker does not suffer (e.g. exchanges may suffer negative reputation cost if attacked while anonymous attackers do not), and (2) the net cost of attack increases over time (e.g. by coin value dropping or the cost of hashrate rising). While we had no evidence for double-spend counterattacks in the real world at the time we wrote the paper, we recently saw what we think are counterattacks on Bitcoin Gold.

Shows three stages of a retaliation game, with green indicating the presently heaviest (canonical) public chain and white indicating a lesser work chain. The top stage shows the beginning of a 51% attack, in which attacker A has sent defender D a transaction but is working on an alternative chain which invalidates the original transaction. The second stage shows the reveal of the double-spend, in which the attacker chain becomes the heaviest chain. The third stage shows the outcome of Ds counterattack, during which D, mining on the original chain, overtakes A’s revealed chain.

In June 2019, we implemented and ran a reorg tracker that today monitors 23 of the most popular proof-of-work blockchains. For each coin, the tracker detects and saves data on all chaintips that were at some point the most work chain. So far, it has observed 40 reorgs at least six blocks deep on Expanse, Vertcoin, Litecoin Cash, Bitcoin Gold, Verge and Hanacoin.

Reorgs and Counterattacks on Bitcoin Gold

Bitcoin Gold hard forked from Bitcoin on October 24, 2017 and had a market cap of $168M as of March 10, 2020. Bitcoin Gold uses a different mining algorithm than Bitcoin; instead of SHA256 it uses ZHash which is intended to be ASIC-resistant, meaning it is GPU-mineable. Unlike Bitcoin, Bitcoin Gold performs difficulty adjustments every block.

Bitcoin Gold has suffered numerous double-spend attacks. BTG’s biggest attack was a 51% attack in May 2018 where 388,000 BTG (~$18 million at the time) was stolen. It was subsequently attacked again in January and February of 2020. Using our reorg tracker, we observed eight reorgs on Bitcoin Gold between January 23, 2020 and February 5, 2020; four of these had double spends. A total of ~12,858 BTG (~$150,000) was double spent. You can see a summary of these reorgs here and the raw reorg tracker output, including all reorgs and counterattacks.

In February, we noticed what appeared to be a retaliation game playing out on the Bitcoin Gold chain. It started as a typical attack, as a transaction was reversed in a double-spent, but then that double-spend was itself reversed, with the original transaction valid again. On February 8th the attacker and counterattacker went back and forth four times over the course of 2.5 hours. The original chain was eventually restored, so the double-spend was unsuccessful. On February 9th and 11th we saw what we call “one-shot” counterattacks: the attacker produced a reorg, and the defender counterattacked once, restoring the original chain.

In the February 8 retaliation game, the fight was over two transactions 757 and d5f, which were replaced, by the attacker, with transactions 50d and f38. In total, 4,390 BTG (roughly 44,000 USD) was stolen from AbC and AYP and sent instead to GVe and GYz. The final reorg, which had length 23, would have earned the miner about 290 BTG (3,000 USD) in block rewards, about 7% of the total amount earned from the double spend. See here for more details. Note that in each pair of transactions, the second transaction spends outputs from the first, that is if the first transaction is invalidated due to a double-spend, the second transaction is also invalidated. We can therefore think of the pairs as units. Both units have the same inputs, but have different outputs, which we interpret as the addresses that were stolen from.

In the following we explain the mining dynamics of the retaliation game on February 8th. You can see the timestamped list of blocks from both chains at this gist. We call the addresses “defenders” which receive the mining rewards on the original chain when it is not the most-work chain. Miners who mine on whichever chain they perceive has the most-work and do not ever mine on what appears to be a minority chain are “bystanders”.

Our node saw four reorgs starting at 06:56 UTC. The first reorg replaced the original chain’s last nine blocks with nine new blocks. In the new chain there were two attacker addresses in each block: GKGUq2p and Gh46Jw1, and there were double-spend transactions in the first new block after the fork block, block 619935. Then, at 07:35 UTC, our node saw another reorg that mined an additional four blocks (with greater difficulty) on the original chain; the defenders were GbWi6y7 and GSsjeTZ. This went back-and-forth again, after which the attacker gave up and mined their last block with a timestamp field of 08:58 UTC. Our best guess at a timeline (in UTC) is the following, based on the timestamps in the blocks and when our node saw the reorgs:

• 4:04 — Attacker starts mining off of the block at height 619934, and mines a block at height 619935, with a double spend
• 6:55 — Attacker mines 9 blocks and its chain overtakes the incumbent chain
• 6:56 — Our node sees and reorgs to the attacker chain. Bystander miners switch to the attacker’s chain and extend it by two blocks
• 7:20 — Defender starts mining and extends the last pre-attack block on the original chain, at height 619943
• 7:33 — Defender overtakes the attacker chain after mining four new blocks
• 7:35 — Our node sees and reorgs back to the defender chain. Bystanders switch to defender chain
• 7:53 — The attacker starts mining again, extending the attacker’s chain which has two additional bystander blocks
• 8:22 — Defender stops mining after 12 blocks
• 8:58 — Attacker overtakes defender chain mining 11 blocks and then stops
• 9:00 — Our node sees and switches to the attacker’s heavier reorg
• 9:14 — Defender starts mining again
• 9:27 — Defender overtakes the attacker chain in total work (same number of blocks) on the original chain and continues mining
• 9:28 — Our node reorgs to the defender’s heavier chain
• 10:20 — Defender reduces hashrate
• 12:15 — Defender stops mining

Where did the hashrate come from?

We do not have conclusive evidence whether the hashrate for any of the BTG reorgs we observed was obtained from Nicehash. This uncertainty is due to the large oscillations in price and available hashrate that occur on BTG even without an active attack. This is in contrast with our observations of the Nicehash market for Lyra2REv3 during the recent Vertcoin (VTC) double-spend attack, during which we clearly saw the price of hashrate spike from its baseline during the attack, and return to baseline once the attack was over.

The frequency of spikes in hashrate availability and price make it difficult to attribute the spikes we did see to attacks. However, there was sufficient ZHash hashrate on the market to perform the BTG attack over the duration of the attack period, and there were hashrate spikes that coincided with detected reorg events.

Nicehash ZHash market summary during detected reorgs. Red lines represent the times of reorg events.

Theory of attack

What we saw is consistent with an attacker invalidating a block on the current most-work chain in order to force their node to mine on a minority chain. This can be done by calling a single command on a Bitcoin Core node so the attacks might not have required writing any new code.

For example, the attacker could have done the following:

1. Use a Bitcoin Core node to make a payment and wait until it is mined in a block
2. Call invalidateblock on the block in the original chain containing the payment transaction (at height 619935)
3. Disconnect from the peer-to-peer network and then clear the mempool to remove the existing payment transaction
4. Launch a rescan on their wallet to make the outputs used in the original payment transaction spendable again, and generate a new transaction spending the same outputs to new destination outputs, which would be mutually exclusive with the original transaction
5. Mine as normal until their chain has more chainwork than the original chain, and reconnect to the peer-to-peer network to notify other nodes of their alternative chain

The defender only has to call invalidateblock on the attacker block containing the double-spend transaction, which will cause their node to continue mining on the original chain instead of reorging to the attacker chain.

It’s possible that in the last two cases, the attacker immediately stopped attacking (called reconsiderblock) once they saw the victim was counterattacking. Perhaps the attacker learned that it was not worth bothering the victim if they were able to defend. In almost all blocks, the defender was GSsjeTZ. The defender address GSsjeTZ had not been used before February 1st and has not been used for mining since the counterattacks.

However, this might not be an intentional retaliation game. Here we discuss other possibilities.

Testing. One alternative explanation is that instead of being an actual counterattack, the counterattacks were simulated by one entity attempting to test counterattack software. One could imagine an exchange, merchant or coin developer that has written infrastructure to automatically counterattack in the event of a deep reorg who wants to test that their software is working correctly. This could explain why there was a counterattack without any double spends on February 6th.

Miner battle. The miners might have been counterattacking each other, not because one or both was interested in recovering the double spent funds, but instead to steal and then recover the block rewards. Again, the fact that the counterattack on February 6th did not have double spends also supports this theory.

Network partition. It might be the case that there was a transient, repeated network partition in Bitcoin Gold and there were two miners on different sides of the partition who ended up mining on their own chains. It’s possible that at the exact same time some client wallet broadcasted a transaction that double-spent outputs to the other side of the partition. We don’t know if any Bitcoin Gold wallet software will do this. The block timestamps are not consistent with this — they indicate that the miners mined aggressively and then stopped several times — but the timestamps could be faked. The attacker and defender addresses were also not used prior or since the attack.

Software bug. It’s possible that the miners involved had some kind of software bug that caused them to not mine on the longest chain, or that they accidentally called invalidateblock.

Random chance. Another possibility is that two large miners just happened to keep finding blocks around the same time and the split was probabilistic. This seems implausible as the timestamps don’t reflect this and the longest reorg was 23 blocks deep.

Conclusion

The increasing depth of hashrate marketplaces may undermine proof-of-work security. In particular, while the existence of a liquid hashrate marketplace suggests that a chain is vulnerable to attack, the possibility that victims counterattack may, in equilibrium, deter attacks from ever happening. If this balance of power is sufficient to protect a chain, this raises the question of how much proof of work is needed to prevent attacks.

In this work we only consider a rational attacker; a sabotage attacker with external interest in damaging the chain might not care about losing money in a 51% attack, giving them an advantage over a potential counterattacker. For such sabotage attackers, the high cost of a 51% attack (e.g. as we see on Bitcoin today) is likely still the important deterrent.

Acknowledgements: We would like to thank our co-authors on the Double-Spend Counterattacks paper, Dan Aronoff and David Parkes. We thank Tadge Dryja, Madars Virza and Gert-Jaap Glasbergen for helpful feedback on this work.

Authors: James Lovejoy, Dan Moroz, Neha Narula