Bitcoin Gold checkpoint rejected a 1,300-block attack chain

By July 12, 2020, Bitcoin Gold’s developers were urging every remaining node operator to install BTG Core 0.17.2 after a checkpoint in that release caused major mining pools and exchanges to reject an alternative chain containing more than 1,300 blocks.

The project characterized the alternative history as a failed 51% attack. According to its incident account, the attacker began mining secretly from a common ancestor on July 1 and released the withheld chain on July 10. Operators already using version 0.17.2 remained on the chain recognized by the project and its principal infrastructure providers.

The episode mattered beyond Bitcoin Gold’s comparatively small network. It demonstrated both the exposure of proof-of-work chains to rented or concentrated hash power and the governance tradeoff created when developers use a checkpoint to prevent the ordinary chain-selection rule from accepting a longer competing history.

What the emergency release changed

The BTG Core repository records version 0.17.2 as a July 2 emergency security release. It introduced a checkpoint at block height 640,650, identifying block hash `000000059ec8884fa4fbbdbe46c09cfb4ecba281dfa2351a05084e817c1200ae` as the accepted block at that height.

Bitcoin Gold’s incident notice identified a different block at height 640,650 in the attacking chain: `00000000635620f22ba8694aea532d51619f8cd060f4e42e85db3cb3a5d1c29c`. A node enforcing the checkpoint could not reorganize onto a chain containing that conflicting block, regardless of how much accumulated proof of work the alternative history presented after the divergence.

The project said it detected the activity before the alternative chain was released, warned pools and exchanges, and supplied the updated software. Its official channel subsequently stated that major pools and exchanges had been using version 0.17.2 when the longer chain appeared.

Those claims establish the project’s contemporaneous explanation, not a complete independent forensic reconstruction. The surviving records do not demonstrate how every public node responded, precisely how much hash power the attacker controlled, or whether the hash power was rented as some contemporaneous reports asserted.

Why the rejected chain was significant

A deep reorganization can reverse deposits that an exchange previously treated as settled. An attacker can deposit coins, trade or withdraw another asset, and then publish a heavier alternative chain that removes the original deposit. Exchanges and other custodial services are therefore the usual economic targets even when the blockchain itself continues producing blocks.

Bitcoin Gold’s checkpoint reduced that immediate reorganization risk for upgraded operators, but it also divided behavior by software version. The project warned that nodes not running 0.17.2 could follow the attacking chain unless their operators upgraded or manually invalidated it. Network safety consequently depended on coordination among developers, miners, exchanges and wallet infrastructure rather than proof of work alone.

That distinction is central to the event-day record. The evidence supports saying that upgraded infrastructure rejected the alternative chain. It does not support the broader claim that no node accepted it or that a protocol rule made future majority attacks impossible.

What remained unresolved on July 12

No authoritative incident accounting available on July 12 established a completed theft, an exchange loss or the attacker’s identity. Coinburn therefore does not attach a dollar-loss figure to the attempted reorganization. Estimates reported elsewhere depended on assumptions about the attacker’s intended transactions and the market value of BTG, rather than a disclosed reconciliation from an affected exchange.

The checkpoint also addressed one identified fork point; it was not a general finality mechanism. Whether Bitcoin Gold would adopt broader protection against later deep reorganizations remained a follow-up question after July 12. Later software changes are outside this event-day account and should not be projected backward into the security properties of version 0.17.2.