Risk Evaluation of 51-Percent Attacks on Ethereum Classic

This document provides an analysis of the context and estimates of risk of Proof of Work finality fraud (51-percent attacks) on Ethereum Classic (ETC).


The following chart and table provide rough estimates for current expected attack costs and revenues. Estimates are derived from the configurable values below, along with a constant block time. The Net with MESS (USD) column can be understood as a minimum payout from fraud that the attacker would need to break even given the cost of the attack.

Duration (HH:MM) Number of Blocks Expense (w/o MESS) (USD) Revenue (USD) Net (USD) MESS Penalty Expense with MESS (USD) Net with MESS (USD)

Confirmation Delay Estimator Tool

should be given a confirmation delay of at least blocks, or about .

These estimates are rough. Factors not taken into account include, but are not limited to: block transaction fee revenues, difficulty adjustment rates, potentially variable hashrate availability (and/or/= cost), nor any “luck” margin for the miner’s target total difficulty.


In August 2020 a series of three 51-percent attacks were published on the Ethereum Classic network. These attacks were:

Date Start Block Blocks Reorged Timespan USD/ETC Th/s Attacker Address Fraud Value Victim References
2020/08/01 10_904_146 3_594 12h 12m $7.81 4.9 0x75d1e5477f1fdaad6e0e3d433ab69b08c482f14e 5.6M USD (807_000+ ETC) OKX
2020/08/05 10_935_622 4_446 15h 37m $7.23 1.3 0x3936968A445B723fdd0C0407efFfcaECb07cab19 3.3M USD (465_444 ETC) Bitfinex
2020/08/29 11_090_590 7_278 26h 20m $6.53 3.2 0x17d1B181C72Be2d3a3212e7725F31F13F7929Ce2 ? ?

In the first of these reorganizations, a bug in the Parity client caused a small network split. The client was unable to handle the large reorganization correctly because of insufficient data pruning rules. The Parity client represented a small minority of nodes at the time.

In apparently all three attacks, Nicehash.com was used to provide the hashrate necessary to mine the attack. Nicehash has since issued a statement noting that they do not endorse such behavior.

Analysis: Chain State Finality

What a 51-percent attack is

A “51% attack” is a scheme in which an “attacker” commits fraud against some victim, with the attacker renegging on their side of some transaction after receiving a counterparty’s corresponding payment.

They do this by secretly mining a chain which critically omits the depositing transaction to the counterparty. Once the attacker receives the victim’s side of the exchange (which was predicated on the attacker’s deposit), the attacker publishes their chain, invalidating their end of the bargain.

History is rewritten, and the attacker has received something for nothing, less the cost of carrying out the scheme.

Hashing Availability (and Cost)

In order for an attacker to mount an attack, they must have the capital necessary to do so.

While a theoretical cost can be derived for arbitrary hash rates, actual material resource availability is both extremely difficult to estimate, and a very important limitation for the attack strategy.

Hashrate cost is a function of (at least) the hardware itself and the cost of running the hardware, ie. electricity.

See Coinbase's How Coinbase views proof of work security for an introduction to general Proof of Work security considerations with regard to hardware.

Mining Algorithm

The original mining algorithm Dagger-Hashimoto (aka ethash) has been changed to etchash on Ethereum Classic.

At block 11_700_000 (2020 November 28), Ethereum Classic implemented ECIP-1099, extending the Hashimoto DAG epoch length by a factor of 2, and thus lowering the requirement for mining hardware memory allocation, which had recently exceeded 4GB.

This change was and is expected to recover and increase hardware availability for the mining algorithm. Greater hardware availability should lead to greater network hashrate.

It also had the side-effect of removing the Ethereum Classic mining protocol from defaults provided by on-demand hashrate marketplaces, notably Nicehash.com.

The hardware available for mining on ETC is now a superset of the hardware capable of mining ETH. This means that the current hashrate on ETH should be considered as a representative minimum of potentially applicable hardware to ETC.

The etchash algorithm is supported by various mining software; including but not limited to PhoenixMiner, T-Rex, Gminer, and lolMiner.2miners

WhatToMine provides a hardware cost/benefit analysis tool for ETC and etchash.

Compatible Hardware Market Share

While Ethereum Classic represents the largest application of ETC-compatible hash power Dagger-Hashimoto/Ethash , there are other applications which together compose a global supply. For example, Ethereum-PoW (ETHW) and Callisto (CLO) both use the memory-hard Dagger-Hashimoto Ethash mining algorithm, but represent a lesser share of the total global supply.

Name PoW Algorithm Hashrate Hashrate xETC Market Cap

Source (JSON)

An emphasis on the technological (eg. hardware) limitations for a network's relative hashrate, determined by its Proof of Work algorithm, is worth repeating. For example, the hashrate on Bitcoin (BTC) at the time of writing is 206_853 Ph/s WhatToMine. However, much of the specialized hardware in use for this application is inapplicable to the Ethash algorithm.

MESS: A Finality Mechanism

MESS stands for “Modified Exponential Subjective Scoring.” MESS is a protocol strategy originally proposed by Vitalik Buterin and modified (slightly) by me, Isaac Ardis. Its specification can be found at ECIP-1100.

MESS was developed and implemented in reaction to a series of three 51-percent attacks occurring on ETC in August 2020 worth around 5 million USD. At this time, the hashrate on ETC was around 5 Th/s, and the exchange rate was around $7 USD/ETC. The attacker's hashrate was apparently acquired via Nicehash.com.

MESS increases the cost of producing a competitive chain by opinionating the network clients toward their incumbent chain (weak subjectivity), at a rate (pseudo-exponentially) proportional to the length of the competitive chain segment. Because of an increased cost of producing a competitive chain, finality expectations for the honest public network rise.

This all seems reasonable! @vbuterin

MESS Protocol

The "penalty" curve implemented by MESS is a function of the length (as timestamp difference) of the incumbent competitive chain segment. This curve is graphed below:

This curve expresses a unitless multiple imposed as a comparative demand on the competing chain segment Total Difficulty (TD). It is defined as a polynomial with a minimum value of 1 (f(0)=1), and a maximum value of 31 (f(25132)=31).

Having a cap at 32x or some value in that ballpark seems totally reasonable; you're right that there's no need to have the ratio keep increasing forever. @vbuterin
The polynomial is defined as follows, with x being the timestamp difference between a local head and the common ancestor (fork block).
const ecbp1100PolynomialVCurveFunctionDenominator = 128;
const ecbp1100PolynomialVXCap = 25132;
const ecbp1100PolynomialVHeight = ecbp1100PolynomialVCurveFunctionDenominator * 15 * 2;

 * @param {number} x - Timestamp difference between local head and common ancestor (fork block)
 * @return {number} - The polynomial value at x
function ECBP1100_Penalty(x) {
    if (x > ecbp1100PolynomialVXCap) x = ecbp1100PolynomialVXCap;
    let xa = 3 * (x ** 2);
    let xb = (2 * (x ** 3)) / ecbp1100PolynomialVXCap;
    let y = xa - xb;
    y = y * ecbp1100PolynomialVHeight;
    y = y / ecbp1100PolynomialVXCap ** 2;
    y = y + ecbp1100PolynomialVCurveFunctionDenominator;
    y = y / ecbp1100PolynomialVCurveFunctionDenominator;
    return y;

This function is then implemented in client canon-arbitration rules as:
 * @param {Block} original - The original (and current) canonical block
 * @param {Block} proposed - The proposed block, displacing the original's canon status
 * @param {Block} commonAncestor - The block these forks (original v. proposed) diverged at
 * @return {bool} - Whether the proposed block should become canonical instead of the original block
function isProposedCanonical(original, proposed, commonAncestor) {
        // Derive the MESS penalty.
        const messPenalty = ECBP1100_Penalty(original.timestamp - commonAncestor.timestamp);

        // Apply the penalty condition.
        if (messPenalty /* [1.0-31] */ * original.TD >= proposed.TD) {
            return false;

        // Reaching here, the proposed segment should become canonical;
        // it has exceeded the TD demand imposed under MESS.
        return true;

MESS Rationale

Alternative Strategies

Given the difficult and urgent problem of increasing finality expectations without increasing hash rate or exchange rate, and without compromising the network's raison d'etre, several strategies were considered. Among these strategies were:

Ultimately, MESS was selected for its simplicity, robustness, and closeness to core principles.

MESS Discussion

Concern: Timestamp Manipulation + Network-wide Sybil Attack
One participant in the discussion of MESS raised a concern as follows:

Your new solution improves the protection but still allows a different selfish mining attack. It requires more hashrate and very high network connectivity.

This is the attack:

We assume the attacker has two times (plus epsilon) the honest hashrate. Let's assume that the victim is waiting for C confirmations. So the attacker first starts mining a public chain A with 1-second intervals and with a hashrate that exceeds the honest hashrate. But he keeps mining his blocks in private. If the honest miners create a block on top of A, then the attacker releases immediately one of his private blocks so that nodes see the attacker block before the honest block, and therefore all the blocks in fork A will be generated by the attacker, and always the timestamp of the best block in A will be in the past. This is a 51% attack combined by a selfish-mining attack.

At the same time the attacker is mining a fork B with more hashrate than A. This fork has normal timestamps (or past timestamps, it doesn't matter). When the fork A is C blocks in length (and the victim has already confirmed the double-spent transaction) he leaves fork A and reveals fork B. Nodes will apply a very low penalty on B because the best block in A has a timestamp that is 10 times closer to the common ancestor than what is expected.

While this attack requires much more resources (2X the hashrate and higher control over the network), it's still possible.

My proposal of the availability rule would not accept fork A as valid in the first place, and therefore the double-spend transaction will never be confirmed in fork A. @SergioDemianLerner

A close look at the reasoning here discovers a few critical issues with the argument.

MESS Known Vulnerabilities

Because the MESS protocol induces nodes to act decisively on an evaluation of a subjective data point (local head), network consensus is vulnerable to bifurcation under circumstances which are expected to be difficult to achieve (from an attacker’s persepctive: costly).

An effort has been made to quantify the expected cost of such a vulnerability. This effort from December 2020 estimated the cost at around “20_000 USD upfront, and 5_000 USD per month to maintain the split.” Veriblock v1 At this time, ETC had a network hashrate around 5Th/s.

It is my opinion on this work that the model it bases its findings on is naive and occassionally incorrect, and that its claims are underestimates (since, at least, complexity is probably expensive).

Of further note is that this vulnerability is a different category of vulnerability than a 51-percent attack. Where the 51-percent scheme is a scenario pitting a fraudster against one or a few victims, the vulnerability resulting from the mechanics of the MESS protocol is nearer in spirit to terrorism (or a controlled market short) since bifurcating the network would likely destroy its value.

Analysis: Consumer Risk Profiles and Transaction Volume

Although chain state finality expectations are important in understanding finality fraud risk, consumer behavior and overall trading volume are equally important to understanding an overall risk profile; the risks from fraud are largely borne and managed by the consumer.

Consumer behavior is important because risk profiles considered in aggregate define the risk exposure for the market in general. In the context of this document, we 'll limit our consideration of consumers to high-profile cryptocurrency exchanges, expecting that they represent a sufficient heuristic for the market at large.

Transaction (trading) volume is important because it represents the value at stake for some measure of risk. It should be noted that in this context, "transaction volume" is not necessarily spot exchange volume, but the volume of transactional value moved through the network. Conventional trading volume, on the other hand, can be managed in proprietary escrow by exchanges at a layer above the network's.

Chain state analysis shows that for the last 7 days from the time of writing, the ETC network had mean and median transaction values of 35 ETC and 43 ETC per transaction respectively, and a mean 8 transactions per block.

Exchange Share Market Volume Confirmation Delay (Blocks) Source
Upbit.com 21.37%
Binance.com ~17+%
OKX.com 4.39+%
AAX.com 2.88%
Gate.io 1.58%
Huobi.com 1.31%
Coinbase.com 1.1% 3000?,10000? help.coinbase.com
Kraken.com 0.9% 40000 support.kraken.com
coinone.co.kr 0.89%
kucoin.com 0.7%
Bitfinex.com 0.11%

Table data source. Do you trade on one of these platforms? If so, please help fill in this table's confirmation delay fields.


Derivation of Cost Values

Since marketplace prices for ETC-compatible hashing power have become murky with the omission of etchash from popular on-demand hashrate marketplaces, we must assume the task of building a usable estimate for ETC-compatible hashrate cost. To do so, we build from a general economic intuition that the cost of hashrate should be slightly (or somewhat) less than the revenue it earns. If the costs exceeded the revenue, miners would not be incentived to commit work to the chain. If the revenue dramatically exceeded the costs, hashrate would rise with increased competition for the spoils of the market inefficiency.

Given these constraints, we provide a sort of reverse-engineered estimation of ETC’s hashing cost using publicly available information for ETC’s younger sister, ETH.

We first show that a cost estimate is close to an expected potential revenue.

If ETH’s hashrate is 929.397 TH/s and the cost of marketplace DaggerHashimoto hashrate is 0.99 BTC/TH/24h and the ETH:BTC exchange rate is 0.07127 then the cost of marketplace DaggerHashimoto hashrate in ETH is 0.99 * (1/0.07127=14) = 13.9 ETH/TH/24h

At these rates, the cost of an equilibrium chain would be at least matching its current hashrate at the current hashrate price 929.397 * 13.9 ETH/24h = 12910.1 ETH / 24h

ETH’s block time is 13.5 seconds yielding (246060 seconds / 24hr = 86400 seconds / 13.5 seconds = 6400 blocks / day) ETH’s block reward is 2 ETH / block. Source

The ETH token currency inflates at at least 6400 blocks * 2 ETH per day = 12800 ETH per day. A competitive chain could be built at a cost of 12910.1 ETH / day if hashrate were purchased in the on-demand marketplace considered.

This analysis seems to fit our bespoke intuitive expectations for price vs. revenue models in a competitive and efficient market.

We now apply this validated intuition as a heuristic for ETC’s hashing cost.

ETC’s block time is roughly the same as ETH’s (though slightly faster because of relatively greater Difficulty volatility), so ETC also produces 6400 blocks / day.

ETC’s block reward is 2.56 ETC, so ETC inflates at least 2.56 * 6400 = 16384 ETC / day.

If we assume that the revenue should roughly match the production cost in ETC as it seems to in ETH then we could expect a mining cost of 16384 ETC * 36 USD/ETC = 589_824 USD / day, or 24_576 USD / hr.