ECBP-1110: Deactivate MESS

[meowsbits]

Discussions-To for ECIP-1110, PR at #520.

This is a place to discuss the removal of the MESS protocol from Ethereum Classic. The code for the change has already been included in the core-geth client as of v1.12.17, but there is still time to revert the change if any solid and consensus-yielding outcomes to the contrary should arise in the next month or so.

Since the original inclusion of the project was generally contrary to traditional opinion patterns in Ethereum Classic about the intended role of network consensus behaviors, and since it was installed as a mitigation for a network hashrate circumstance which is no longer the case, we, the core-geth developers, expect contra opinions to be in the minority, and have accordingly oriented the decision as an opt-out decision, rather than the more common opt-in decision.

PTAL. Your feedback and questions are welcome here.

See also:

• Path to disabling MESS: https://github.com/orgs/ethereumclassic/discussions/492
• Living document with ETC hashrate analysis: https://meowsbits.github.io/51-percent-docs/

[realcodywburns]

Is the intent to remove it entirely or remove it as default?

I'm in favor of removing it as default. MESS was always a choice and depending on a node operators risk tolerance they make their own decisions.

I would hesitate to remove it entirely. I don't see it as tech debt since, at some future point, it could be used again. Since etchash is the dominate algorithm now, new asics will be built. The same people who were able to aquire the means to be more than lucky at hashing are still in the space.

TL;DR its better to have(inactive) and not need than need and not have.

[meowsbits]

Yes, the current implementation only deactivates the logic as a default on the (de)activation block, it does not remove it. From an implementation standpoint, this was a necessity in order to be able to have core-geth clients deactivate simultaneously, which we consider the safest path; there is safety in numbers given the subjectivity.

The tech debt is fairly small, since most of the logic can be segregated by file (eg. ./core/blockchain_af.go), and the integration points with the upstream code are few and fairly self-contained. Even if we were to remove the code, git would maintain the history of it, and a re-implementation would start with a reapplication of those patches.

But your point is well taken, and we hadn't settled on whether in 6 months time to delete or maintain it, and I think your argument for its maintenance are convincingly strong.

As it stands, MESS's activation and deactivation can both be configured with the command line, so operators can configure behavior without touching the code:

./build/bin/geth --help|grep ecbp1100
    --ecbp1100.nodisable           (default: false)  # should have been 'ecbp1100.nosafety', prevents safety mechanisms from turning MESS off on low peer count or stale head
    --ecbp1100 value               (default: 0)
    --override.ecbp1100.deactivate value (default: 0)

[IstoraMandiri]

Agree with @realcodywburns reasoning.

Unless I am missing something, it seems like free optionality to keep the logic but have it disabled by default, so it can be enabled manually if needed.

[bobsummerwill]

We could certainly just switch the default to off but not remove the MESS support from the code-base, but there two things which everyone needs to be aware of were we to take that approach:

1. If MESS is not actually running on sufficient nodes then it will not help if we have a 51% attack. We could coordinate a "please turn MESS on, miners" which could potential protect against further attacks, but the first attack will not be stopped.

2. We really do not want to only have a subset of nodes running MESS (or worst case would be 50-50) because that risks a permanent chain-split. The MESS nodes will not follow the longest chain, which is the essential component of Nakamoto consensus. That "most work chain" rule is strictly necessary as an objective means of attaining consensus in any situation.

That second point is crucial. The introduction of MESS introduced subjectivity into the consensus process as a tradeoff for less likelihood of long chain reorgs. That tradeoff only really works if nearly all nodes are running MESS.

So, I think, to be safe we either need all nodes or no nodes to be running MESS. Removal of MESS is switching from the equilibrium we have been following since 2020 back to the original Nakamoto consensus. If we do that then I don't think keeping MESS around but off by default necessarily helps us a great deal, but I am open to doing so, as long as we are all clear in our understanding of the above.

[stevanlohja]

1. Remove MESS entirely if its purpose has expired. MESS falls outside the existing consensus protocol and risk of network fragmentation if not universally implemented. MESS introduces subjectivity into block selection from traditional objectivity of consensus mechanisms. Essentially this is why MESS is a default option. Simply removing it as a default option will not prevent it from being leveraged and have that risk of network fragmentation. If the community feels confident that the network can rely on objective consensus, then retire MESS completely.
2. Are there any eclipse attack tests for MESS?

[meowsbits]

Simply removing it as a default option will not prevent it from being leveraged and have that risk of network fragmentation.

So, in metaphor we have

• footgun (misuse leading to self- and network-harming behavior), vs.
• shotgun in closet for protection

If the network experiences a recoverable 51% attack (or, more likely and better, the outlook of one), the only possibility for a strong reaction will be if the tools needed are already at hand. To disseminate CLI instructions is quicker, less risky, demands less centralization, and can be done ahead of time, versus the production and distribution of an update.

IMO we just need to make it clear that using the --ecbp.1100 flags is unsafe and counter-productive unless done in concert with the majority. As @realcodywburns says, "better to have (inactive) and not need, than to need and not have."

But with this said, personally, I'm on the fence because I don't like MESS and don't think its really a good "gun" (or rather, that the/a 51% situation evens demands this kind of reaction) in the first place, so I'll be pretty easy to sway toward deletion.

[meowsbits]

2. Are there any eclipse attack tests for MESS?

An eclipse attack is where an attacker "surrounds" a target entity (the victim), and coerces them into believing that the network they see is representative of the network at large. In order to do this they need to suppress or capture the networking of the victim.

MESS does not modify the node's networking protocols or patterns, so we expect exposure to such an attack to be maintained invariantly. There are, strictly speaking, no "eclipse attack tests" for MESS because there are no eclipse attack tests for Ethereum or ETC. In the trustless system, there is no waterproof way for any entity to know whether they are connected to the "honest" network or exclusively to a malicious one. However, this strategy has been studied, and subsequent countermeasures related to the Kademlia protocol have been adopted; see here.

However, the impact and scope of an eclipse on a MESS-activated node (rather than exposure to this attack) are worse compared to an objective node. After an eclipse attack an objective node will reorg to the honest chain immediately on knowledge of it, where a MESS-influenced node will be more reluctant to do so (following the time-penalty curve), approaching that "new" chain with the same skepticism it would an attacking chain. The M (Modification) in MESS causes the node to be sure to eventually reorg to the honest chain, where the original ESS proposal could have practically prohibited it indefinitely.

With respect to this asymmetry, core-geth's MESS implementation has (by default) some safety mechanisms that increase the challenge of an eclipse for such an attacker, and intend to limit the scope and impact of this category of attack by disabling MESS automatically given failing conditions. A low-peers threshold disables MESS should the node's peer count be below minArtificialFinalityPeers (== defaultMinSyncPeers == 5), and a stale-head threshold disables MESS should no new head be imported in artificialFinalitySafetyInterval == 30 * 13 = 390 seconds. These mechanisms are indeed tested, eg. TestArtificialFinalityFeatureEnablingDisabling.

[IstoraMandiri]

@bobsummerwill @stevanlohja

You bring up good reasons to remove it entirely.

I can now see that having it available under a flag it is not "free optionality" as I previously thought, but introduces a potential footgun for miners.

If it's absolutely needed (which seems very unlikely going forward), a new version could be released with MESS enabled by default, but as a non-default option, it presents a danger if a subset of miners turn it on for whatever reason.

[gitr0n1n]

Yes, i think the question left open is. If we do not remove it entirely, have we created an easier way for an attack on the loyal 150 TH/s of hashrate? In which case, shouldn't we remove that unknown threat and lean into the standard consensus that existed before adding the MESS optionality into the client in 2020?

I'm not an expert enough in the field to answer that question, but understand it is an open question in the dialogue here.

Could this threat of a bad actor utilizing MESS to attack the network be a reason to fully remove the option of utilizing MESS, opposed to only deactivating it as a default?

[meowsbits]

Much of this discussion has been about whether or not the MESS implementation should be deleted from client codebases, rather than whether it should be deactivated at the proposed time. The question of deletion supposes that it will in fact be deactivated, and since we need to have it in the codebase to deactivate smoothly, the deletion question might be well suited to its own discussion under its own rationale in the future, after its pending deactivation in about 3 weeks.

[meowsbits]

Since no one has yet provided a contra argument, and I think its worth having on the table for consideration, here's my take on why not to deactivate MESS.

ETC's current hashrate is currently about 150 Th/s. If we include other Dagger-Hashimoto compatible hashrates, we might come to about 200 Th/s. Back when ETH was on PoW, its hashrate was on the order of 1000 Th/s.

So this leaves around 800 Th/s of unaccounted-for hashrate. This is potential hardware and electricity that is not being currently applied to ETC or her hashrate-cousins, but which maybe could be. And if it were, would clearly pose a potential risk for a 51% attack on ETC.

Coinbase provides rationale for why this is still a dangerous situation for ETC, since clearly ETC does not dominate the use of globally-available compatible hardware and energy.

The question then, in assessing this risk, becomes whether targeting this hardware+energy potential maliciously as fraud on ETC is profitable relative to its current application, whatever that is. One critical factor here is the risk-exposure assumed by transactors on ETC (primarily exchanges), where sufficient confirmation delays would minimize it, and where (historically existing) risky confirmation times would increase it.

[meowsbits]

My stance on MESS is, and has been, that MESS does not belong on ETC because the 51-percent-attack problem is not ETC's problem. It's a risk-exposure problem that belongs to the people making transactions on the network, and transactors should take the responsibility for their own risks when they blow up. A 51-percent attack happens, and can only happen, when a transactor makes a bad decision about a confirmation delay given some transaction value.

MESS does have potential tail events (ie. vulnerabilities), and their risks are poorly-defined (which in itself is risky). So when ETC installed MESS to artificially increase finality it transferred risk from the transactors to the chain. In exchange for this transferred risk, ETC got the confidence of exchanges back (confidence which was originally unfairly demoted in the first place, by misunderstanding or misrepresenting the 51-percent finality "problem" as one belong to ETC, not the exchange(s)). And their reinvigorated confidence was really superficial, since the risk was not eliminated, only asymmetrically and opaquely transferred (so the confidence was a fool's confidence).

We need to be careful, diplomatic, and open with exchanges as we move toward deactivating MESS. If exchanges shifted ETC confirmation delays lower because of MESS, they need to readdress those values under the new situation. And they need to do so knowing that we're not going to be bailing them out anymore.

[DonaldMcIntyre]

MESS is a change in consensus rules under the guise of a client feature. If we have a POW blockchain where a group of nodes arbitrarily and subjectively decide to not accept the most work done then that is to change the consensus rules. In my opinion, MESS should be removed completely as it is a violation of Nakamoto Consensus.

Separately, the fact that by adding features to Core-Geth by default or not-default results in a de facto activation or deactivation of consensus rules or extra consensus features is a dangerous way of managing these things. Core-Geth should be always shipped with the barebones functionality of the ETC protocol, nothing more. If node operators or miners wish to change rules or activate or deactivate features that should be their conscious decision and action.

That MESS was activated just by developer decision and the great majority of the network just followed because they are not paying attention is a very bad precedent in ETC.

Core-Geth developers should not unilaterally decide feature activations, much less changes to consensus rules such as MESS, through the "default/not-default" method. Things should not be by default, unless they are actual consensus rule changes agreed upon by the whole ecosystem by rough consensus.

This is why Core-Geth should be moved back to the ETC community repo. Core-Geth is not the property of few developers or the ETC Cooperative, it doesn't matter if they are financing it. Therefore, it should not be the prerogative of the ETC Cooperative to activate and deactivate features by the "default/not-default" method, even if public discussions like these are had that give the impression of community consultation but are not.

Finally, this proves the risk of developer driven consensus changes through automatic upgrade methods, such as happens with ETCMC. It is the same effect: The ecosystem does not pay attention to ETC and its rules because it is small, marginal, and not important, so developers can introduce changes by "default/not-default" method just because nobody pays attention and everyone just upgrades blindly with the "automatic upgrade" button to whatever is the last version.

All these things are very dangerous and behaviors that should be avoided in ETC, especially in the Core-Geth client which is the ETC community public bellwether client.