Ethereum Classic 51% Chain Attack July 31, 2020

Based on the chain split diagnosis by Yaz Khoury, Sam Johnson and Austin Roberts, and on on-chain data Bitquery indexed in 2020.

What happened

On 31 July 2020, Ethereum Classic suffered a 51% attack. One miner, 0x75d1e5477f1fdaad6e0e3d433ab69b08c482f14e, mined more than 3,500 blocks in secret, a fork running from block 10904146 to 10907740. The miner kept these blocks private for hours and then broadcast them. The secret chain carried more work than the chain built by everyone else, so the network had to accept it, replacing 12 hours of history with the attacker's version.

What else happened

Not all nodes handled the event the same way. Nodes running Open Ethereum, Bitquery's among them, did not accept the attacker's blocks. The network split in two, depending on which software a node ran:

1. Geth and Hyperledger Besu nodes accepted the attacker's blocks and followed the heaviest chain.
2. Open Ethereum nodes stayed on the old chain.

Earlier in July, Open Ethereum had announced it would drop support for ETC. We did not expect the software to break in such an odd way, given that nobody had changed it.

What it means for users

Some ETC transfers made in the 12 hours from 16:30 UTC on 31 July to 03:30 UTC on 1 August are missing from the new chain. A payment sent in that window may never have reached the recipient's wallet.

For part of 1 August, some miners, probably running Open Ethereum, kept mining the old chain. Transfers made by wallets on those nodes never reached the main ETC chain.

What it means for miners

Honest miners lost the rewards for blocks they mined during the attack. Some also wasted hash power on the old fork after the attack.

What it means for all of us

Proof-of-work blockchains are often seen as safer than other consensus types. But their finality rests on probability, which gives a level of confidence and never reaches 100%:

Confirmation probability

Confidence starts at 0% while a transaction waits outside a block. It climbs toward 100% as more blocks pile on top of the block that holds it. Under normal conditions proof of work gets there fast, to about 99.99999% after 6 blocks. That is why wallets and exchanges wait for a set number of confirmations.

A low probability does not mean an event will never happen. Nassim Taleb gives many examples in The Black Swan.

A balance in your wallet is final only with some probability, never with certainty. This attack showed that no practical waiting time makes it 100%. Few people expected 12 hours of history to vanish, but it did.

Mining Power

The attacking miner, 0x75d1e5477f1fdaad6e0e3d433ab69b08c482f14e, needed more than half of the network's mining power to sustain the attack for 12 hours.

The price of rented hash power on NiceHash's daggerhashimoto market rose during the attack:

Mining hashrate price spike in the market

The chart uses UTC+3. The price spike (blue line) starts when the attack starts and ends when it ends, and it was the all-time high for hash power on that market. That could be chance, but the timing points to the attack.

The cost of the rented hash power can be estimated from the chart:

5 BTC / TH / day * 1/2 day * 7 TH= 17.5 BTC

This assumes the attacker bought all 7 TH/s on offer, which is the same order of size as the ETC network hashrate shown by 2miners.

So the attacker spent about 17.5 BTC ($170K at the time) to control the network for 12 hours.

The miner first appeared on 29 July and for three days mined about 30 blocks a day:

Activity of the miner, from Bitquery data on the non-reorg fork

On-chain activity during the attack

This first look uses only the non-reorg data, without the attacker's blocks. Because Bitquery ran Open Ethereum nodes, it held data for both forks and could match one against the other.

While the attacker mined the hidden fork, nobody else could see it. Users kept sending transactions to the public chain. The largest ETC transfers in that window were:

Data is from Bitquery.io non-reorg database

Some of these transfers also made it into the attacker's chain, including the largest. It sits in block 10906346 on the non-reorg chain and in block 10907763 on the reorged chain.

Others did not. For example, the transfer 0x069db204ea87f62817dff7320d0177815c9a7f56811a3a4be00e0c2d862dda39 is missing from the current chain, so balances such as that of 0x97b2a6ca77e2a0fccd15e082b27cb566ddb31ee4 differ between the two chains.

This chain of transfers does not appear on the reorged chain:

Transfers that exist only on the non-reorg chain

At the time, Bitquery was moving its node to Geth so it could match transactions across both chains. The differences between the forks were large, and some addresses looked like double-spenders. The follow-up analysis confirmed it.

Conclusion

The attack was a major failure for the ETC blockchain. It can happen on any proof-of-work chain where hash power is cheap to rent.

The evidence shows the attack was deliberate: the miner rented hash power from outside sources.

Node software did not behave the same everywhere, and that split made the damage worse.

Also read

• Attacker Stole 807K ETC in Ethereum Classic 51% Attack
• Ethereum Classic Attack, 8 August: Catch me if you can
• How Upbit hackers laundered millions using crypto exchanges?

First published in August 2020. Updated on 30 October 2026 by the Bitquery team, with help from AI tools: links to the Ethereum Classic explorer, which no longer serves this chain, were removed, the Coinpath link and an AI-tracing box were dropped (neither covers Ethereum Classic), and the text was edited for clarity. The figures are unchanged from 2020.