Ethereum Classic was reorganised three times by rented hashpower

Inherited archive entry · retained from the earlier edition. Its factual, legal and policy claims have not all been reverified for 19 September 2026. Research scope.

Three reorganisations in one month

In August 2020, Ethereum Classic's own account, published in a later explainer on the chain's official site, records that the network suffered three 51% attacks that month, in which exchanges 'lost millions of dollars in what are called double spends'. An attack of this kind does not forge new coins or steal from arbitrary wallets; it lets whoever controls a majority of hashpower on the affected chain rewrite recent history, deleting a transaction that had already been accepted, typically a deposit, and replacing it with a version that sends the same coins elsewhere. Ethereum Classic, a minority proof-of-work chain sharing a mining algorithm with a much larger network, was a comparatively cheap target for rented hashpower.

Why work-based security is relative, not absolute

The original proof-of-work design states its security condition directly: the system holds 'as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes'. That condition is about relative power on a specific chain, not an absolute amount of hashpower. A chain that shares a mining algorithm with a much larger network sits beside a standing pool of hashpower that can, in principle, be redirected against it for a limited time, which is what a rented-hashpower attack does: it does not require building new machines, only paying for existing ones for long enough to outrun the honest chain's recent blocks.

What the response changed and did not change

The chain's developers proposed ECIP-1100, Modified Exponential Subjective Scoring, on 9 September 2020. Its own motivation section frames the problem narrowly, as low hashrate producing 'inconvenient and undesirable finality rates', and its mechanism makes nodes progressively more reluctant to accept a large, late-arriving reorganisation the older it is. The proposal is explicit that this raises the cost of an attack rather than making one impossible: by one estimate in the document, an attacker needs roughly thirty-one times the network's ordinary total difficulty to overcome the added resistance. No hard fork was required; adoption depended on individual node operators choosing to run compatible client software. This is a mitigation calibrated to a specific, known threshold, not a proof that a well-funded attacker is now excluded.

Questions to carry forward

• What does current rentable hashpower on the relevant mining algorithm cost relative to a target chain's own hashrate?
• Has a chain's reorganisation-resistance mechanism been adopted broadly enough among node operators to be effective, or only by a subset?
• How many confirmations does an exchange or counterparty require for a minority proof-of-work chain, and was that threshold set after these attacks?

The 2020 attacks were not a flaw unique to Ethereum Classic's code; they were a demonstration of what the whitepaper's own security condition looks like when it fails to hold for a specific, smaller chain. Confirmation depth and mining-power comparisons are chain-specific facts, not properties of proof of work in general.