Risk Evaluation of 51-Percent Attacks on Ethereum Classic

Summary

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 under MESS.

The dataset without MESS is essentially driven by the efficiency ratio, since the attacker is assumed to recoup their costs through block rewards, as any miner would be. The Net (USD) column can be understood as a minimum payout from fraud that the attacker would need to break even given their costs associated with hardware acquisition and other overhead (defined reductively via the Hashrate Efficienty Ratio input). An efficiency ratio of 1.0 is equivalent to a scenario where cost is equivalent to revenue.

Striked headers indicate the planned deactivation of the MESS artificial finality feature.

Confirmation Delay Estimator Tool

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.

History

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

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.

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

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;
};

/**
 * @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:

• Several checkpointing protocols, which depended on the assertion of an authority entity, compromising the core principles of decentralized and permissionless consensus, and necessitating the intractable problem of to Whom to the authoritative trust would be assigned.
• A proof-of-proof protocol which delegated trust(lessness) to a third-party authority entity (ie. Bitcoin). This has the same fundamental problem as checkpointing: authority assignment.
• A peer-to-peer endorsement scheme intended to materialize practical heuristics about chain segment preference (ie. following established and human-trusted miners), but again, these compromised the rationale of the network's foundational principles.
• PirlGuard, a subjective scoring strategy, which was evaluated to present unacceptable critical attack vectors.
• A monetary policy adjustment that would increase the rate of inflation in the short term, and decrease it in the long(er) term, while keeping the overall anticipated supply constant. This would have been expected to increase the incentive to mine during the period of paucity, but would have compromised the promises implicit in the design and purpose of the policy.
• Do nothing. A valid argument can claim that the issue is one of criminal behavior and risk management practices of the defrauded consumer, not the network protocol. An adequate confirmation delay relative to transaction value mitigates the risk effectively. This option was impossible due to constraints and pressure from the community. Network finality is associated with network utility.

MESS Discussion

Concern: Timestamp Manipulation + Network-wide Sybil Attack

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.

• If the attacker has two times the public hashrate (plus epsilon) ((2*publicHashrate+e)/2), and must mine the public chain as well as a competitive chain simultaneously, it stands to reason that their assumed hashrate will be insufficient. If the attacker spends half of their available hashrate (1*publicHashrate+e) mining the public chain, the resulting hashrate on the public chain will be 2*publicHashrate, while the attacker will have only 1*public hashrate to spend building the private competing segment.
• 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. Here, the attacker (or the author) underestimates the cost of producing blocks sufficient to suppress those of the rest of the network. If the attacker has 1*publicHashrate applied to this purpose in competition with the honest miners, together themselves representing 1*publicHashrate, the attacker's hashrate will only be able to produce a winning block 50% of the time relative to the honest public. With that understanding, obviously the expectation for the attacker's success approaches zero, since perfect success can be quantified as a sequential n trials with P(n)=0.5**n If the attacker is unable to provide a replacement block only once, the honest miners will insert a canonical block with a current timestamp, unraveling the strategy entirely.
• Generally, the feature where [the attacker] releases [...] one of his private blocks so that nodes see the attacker block before the honest block would be practically extraordinarily difficult to achieve. It would require a comprehensive view and control of the global, decentralized, permissionless network. An attack of this variety and magnitude would effectively become a network-wide Sybil attack, a circumstance no blockchain, real or theoretical, would be equipped to handle.

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.

MESS Deactivation (January 2024)

Since the introduction of MESS on Ethereum Classic in late 2020, Ethereum (ETH) has dropped PoW in favor of a proprietary Proof-of-Stake block emission strategy. This has left Ethereum Classic as the leading consumer of applied Dagger-Hashimoto-compatible hashrate in the cryptocurrency ecosystem; see Hardware Market Share.

The rationale behind its removal assumes that the risks inherent in its maintenance and operation, which are not well defined, weigh more heavily in the balance than the risk to the network of another 51% attack given ETC's dominance in the applied Dagger-Hashimoto market.

Community discussion around deactivation can be found here.

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.

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

Appendix

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.