[Discussion] ECBP-1100: Modified Exponential Subjective Scoring

[meowsbits]

Discussion for https://github.com/ethereumclassic/ECIPs/pull/373, and an update to that original at https://github.com/ethereumclassic/ECIPs/pull/384.

[realcodywburns]

It seems a little convoluted, but it will eventually resolve to the 'correct' chain if given malicious reorg.

"Reasonable operating bounds for the victim of an eclipse attack to eventually recover and rejoin the network. "

31 x difficulty ceiling seems overly cautious, given the bounds of the difficulty adjustment algorithm and could cause longer than desirable delays before a node would reorg to a proper chain, but it does allow for eventual resolution.

Since this is an ecbp, the activation block could be genesis or any random block and, since this is only active on a synced chain, have the same effectiveness. The coordination across nodes isnt as important since this allows a single node a ojective evaluation of incoming reorg blocks with eventual resolution even if it is 'wrong'.

This solution could work on a network with some nodes using the 'pirlguard' proposal and makes the same assumption that as long as a majority of nodes are evaluating reorgs with the assumption they are unusual outside of some window (n blocks for pg or 200 sec for mess).

[realcodywburns]

Maybe there is a need for an overarching "core principle / best practice" : "small reorgs are normal and healthy, large reorgs are suspicious. given a reorg of unusual length; nodes should evaluate the current chain head they have with preference over the incoming chain with longer length or higher difficulty" This would cover PG, MESS, and possibly checkpointing.

Your node is your castle, defend it from reorgs how you like. But if you have no defence (mess or pg not active) your node is less secure and possibly on the wrong chain. I think it should be fine if the solutions eventually resolve at different rates, as long as they resolve on the same chain.

As long as the majority of nodes are suspicious of reorgs, the network is more resistant to malicious reorgs

[meowsbits]

Maybe there is a need for an overarching "core principle / best practice" : "small reorgs are normal and healthy, large reorgs are suspicious.

Yes!

31 x difficulty ceiling seems overly cautious

Understood. I wanted to start with the "most reasonably conservative" value and work our way toward efficiency from there. My reasoning being that an eclipse of one or a few (arguably ill-equipped) nodes is inconvenient but recoverable (and hopefully increasingly unlikely for higher-staked nodes, like miners and exchanges), but a too-low ceiling could be permanently bad for everybody. Do you have a counteroffer? 22x? 11x? 3x? Keep in mind, too, that the value may be modified later if desired.

The coordination across nodes isnt as important since this allows a single node a ojective evaluation of incoming reorg blocks with eventual resolution even if it is 'wrong'. [...] I think it should be fine if the solutions eventually resolve at different rates, as long as they resolve on the same chain.

The nodes don't have an objective evaluation, only ("weakly") subjective.

TLDR: We do want nodes to be suspicious of the same reorg at pretty close to the same time, because if they're not, they can start getting suspicious of each other.

Your node is your castle, defend it from reorgs how you like.

If the castles defend themselves in coordination, the kingdom is pretty safe. If not, the kingdom can get picked apart (especially if the differences are observable).

If nodes resolve at non-trivially different rates and if the unresolved chains share some portion of the mining power (honest or not), the probability of the partitions to resolve back to a unified network starts diminishing, depending on the difference of the acceptance rate and the relative hashrate shares.

Depending on the acceptance/rejection differences between clients, any variance has some opportunity for exploit by an adversary; and we have to expect that some variance is a necessary characteristic of the subjective view. We can use Pirlguard's 20 "shallow threshold" as an extreme example, where an adversary may launch repeated serial or parallel propositions of 20 block segments. At one of these times of broadcast, presumably some portion of the network will be on block n and some on block n-1, and thus some (assume 50%) will allow one of these reorgs (n-1), while the others will not. This split continues depending on the hashrate split (again, have to assume 50%), and as it continues unification becomes less and less likely (and subsequent attacks go on 50% sale). This, in principle, is also the case with any subjective acceptance arbitration, especially network-diverse implementations. The "weak" part of the ESS idea is to continuously marginalize the normal, short reorg window so that it approaches a resemblance of objectivity. This continuous marginalization is why I think the sin differentiable ceiling transition is important, even though its exploit would be a (hopefully!) far-edge case.

the activation block could be genesis or any random block and, since this is only active on a synced chain, have the same effectiveness.

All observable discrete and non-unified arbitration points in subjective acceptance are technically exploitable. If the genesis or any historical block is the activation block, then an attacker can differentiate nodes who have upgraded vs. those who haven't (say, by clientId version), and can launch a targeted attack when, say, 50% of the network is upgraded.

[meowsbits]

All observable discrete and non-unified arbitration points in subjective acceptance are technically exploitable.

Actually, even the activation block (say, a future, non-zero block) is exploitable, if an attacker can propose an adversarial segment when they first receive the broadcast of block n. To address this (although I think it's practically a rather edge case), one option would be to randomly determine the actual activation using the block with number n as a "seed," ala

// concreteActivationBlock returns the "real" activation number as a random but objective value generated from a specified "imaginary" value.
func (bc *BlockChain) concreteActivationBlock(imaginaryNumber uint64) uint64 {
    if block := bc.GetBlockByNumber(imaginaryNumber); block == nil {
        return 9999999999999
    } else {
        return imaginaryNumber + (block.Nonce.Uint64() % 1000)
    }
}

But again, this only makes life a little more annoying for an adversary, it doesn't perfectly solve it.

[realcodywburns]

it is trivial for malicious people to attack now.

Neither solution should ever resolve to a minority fork given enough time. So even if the minority of nodes have either solution they should eventually reorg to the same chain as the unprotected nodes. This is at least the case with pg. if not so with mess, then it has to be implemented as a fork.

The activation is transparent to both sides. Setting the block at genesis(or some block infeasibly in the past) would mean all upgraded nodes are protected and give reason to upgrade as well as give us a metric of how protected the network really is. The bad guys are watching us build the defense in real time, there is no need for a grand opening.

Judging from etcnodes, most nodes are very slow to upgrade. Until either solution protects 51% of the network, there is risk that the majority could be on a different fork and they will have to wait until the chain eventually resolves. pirlguard with 250 block penaltyCheckLength is ~30k blocks until it resolves or n*(n/2) assuming it is a sustained attack.

The attack pattern we have seen appears to be massive reorgs broadcast at once and then the miner disappear. both solutions work best on the attacker not activly mining openly with a majority hash rate. If they are actively mining, The pg solution gives honest nodes an opportunity to defend the minority fork until the majority head is 30k beyond it before accepting. It is the same as saying 250 block reorgs are the max normal reorg, if a reorg is longer than 250 blocks it needs to be 30k blocks long to accept.

The hard stops are easily calculated and are goal posts. if someone is able to trivally make 30k reorgs we are they make the chain. It does open the door fo reorg as a service, but thats a different topic all together. There is 3x the network hashrate available for rent so the difficulty is somewhat unreliable.

[meowsbits]

Gotcha.

Neither solution should ever resolve to a minority fork given enough time

You're right. There are, IMO, important nuances though: How long is enough time? (what conditions allow resolution)? And, how robust are they to circumstances that create the bifurcation in the first place?

I've been trying to figure out a "general principle"/heuristic for evaluating these subjective arbitrations. The best I have now is "rough edges are repulsive." Where acceptance arbitrations that use "goal post" numbers in a yea/nea way (like pg's 20 or 250) are more likely to present a vulnerability to partitioning than "smooth edges."

The condition for bifiurcation/resolution in pg is chain length, which can be established and maintained by an adversary with enough capital quite simply (create fork with 20 or 250 block reorg(s) to hit the n vs. n-1 network discrepancy, maintain length as desired, or repeat). The necessary condition for a MESS partition(s) is a near-constant total difficulty ratio, which, even for an ultra-capable attacker, would be extremely (and increasingly) challenging and risky to establish and maintain over time.

The activation is transparent to both sides. Setting the block at genesis(or some block in the past) would mean all upgraded nodes are protected and give reason to upgrade as well as give us a metric of how protected the network really is. The bad guys are watching us build the defense in real time, there is no need for a grand opening.

I hear you. My reasoning for an activation number is not really "a grand opening." Its:

• If nodes are slow to upgrade, then if they upgrade after the activation number, the net effect is the same.
• If (the mining subset of) nodes upgrade on time, then the opportunity to stage a targeted attack is limited to a single block (rather than the duration of the population upgrade).
• It's a familiar pattern and gives people a number to hold on to.

Do you see any downsides to the activation number that I'm not seeing?

Anyways, and by the way, there's currently a flag --ecbp1000=<number> and an RPC method admin_ecbp1100(number) in the implementation at core-geth that allow the operator an accessible override if they want.

[realcodywburns]

No real technical downsides.

The ones I can think of: 1) an attack occurs between code release and the activation block then all the nodes could have been protected if it was active by default when upgrading. 2) It will give a false sense of security if the majority of the nodes are not capable of using mess on the blocknumber. Then in the event of an attack mess looks like it was unsuccessful in spite of it not being capable of working 3) 11% of the node on mainnet are running openethereum, 13% run multigeth still for some reason; only about 13% are > v1.11.13 The likelihood of the entire network coordinating together to update to the latest version of any node software is slim.

It would be an annoyance for someone to trivially reorg at the limit, but it wouldn't be sustainable and is the same as if they were attacking the safety window in mess. These attacks are possible now and are uncommon. In either case, double spends would be under the window of reasonable actors tolerances and It has been years since exchanges have used such short confirmation times. The appropriate thing for a node to do if a node is receiving several invalid blocks is to disconnect for the peer.

The Safety Interval is interesting for edge cases also. If an attacker had some amount of hash > network hash power, couldn't they artificially raise the difficulty on the main chain and then abandon it for a privately mined a fork while the low hash rate chain struggles with too much difficulty? I think the longest block time on the network were shorter than what is proposed though.

20 is very low for pg on a public chain and would be trivial for attackers we have been seeing to overcome. The difficulty multipliers in pg max out at 50 gh so it is essentially useless as is and would need to be adjusted.

I like flag options, it lets other custom configurations use mess or whatever if need be.

[meowsbits]

the same as if they were attacking the safety window in mess

Can you say a little more about what you have in mind here? Do you mean the "external safety mechanisms", like the minimum-peers condition or the head staleness check? Otherwise, the feature I like most about MESS is that it doesn't have a discrete window (ie rough edges). The attacker needs to maintain a near-constant competing difficulty ratio, and if they fail that, the probability of network resolution rises near-exponentially with each next block (on either chain). Kind of like walking a tightrope that starts to slope up quite quickly.

I think the longest block time on the network were shorter than what is proposed though.

I hope so! :joy: From my statistics, the 99th percentile of ETC historical block times over the last ~2 million blocks is 59 seconds, so I doubled that.

[vbuterin]

This all seems reasonable!

There is no Edge-of-Eternity attack vector (no vulnerable focal points for an attacker to target).

Not sure I understand this. I assume "edge of eternity attack" is an established term in ETC land discourse that I'm just not familiar with? My guess is that this means something like "there's no fixed ratio of hashpower that an attacker can split between two chains to cause a permanent split between them", which seems true, though with the caveat that doesn't rule out the possibility of a variable-hashpower balancing strategy....

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.

This may just be my own bias, but I find the notion of using floats in the consensus-layer spec definition to be quite :vomiting_face: :vomiting_face: :vomiting_face: ; you're basically importing the entire IEEE 754 floating point spec into the de-facto consensus rules (and in addition the precise calculation of the sine in floating point... are you sure there aren't subtle differences between languages?). Ethereum EIPs and eth2 EIPs all stick to integers (and eth2 goes even further, sticking exclusively to positive integers!), and I think this approach could be done entirely using integer math if desired!

The eth2 way of doing this would be an approximation like:

CURVE_FUNCTION_DENOMINATOR = 128

def get_curve_function_numerator(time_delta: int) -> int:
    xcap = 25132 # = floor(8000*pi)
    ampl = 15
    height = CURVE_FUNCTION_DENOMINATOR * (ampl * 2)
    if x > xcap:
        x = xcap
    # The sine approximator `y = 3*x**2 - 2*x**3` rescaled to the desired height and width
    return CURVE_FUNCTION_DENOMINATOR + (3 * x**2 - 2 * x**3 // xcap) * height // xcap ** 2

The if tdRatio < antiGravity check would then be if proposed_subchain_td * CURVE_FUNCTION_DENOMINATOR < get_curve_function_numerator(proposed.Time - commonAncestor.Time) * local_subchain_td.

Here's a comparison chart of the sinusoidal function versus this one: https://imgur.com/XNXGwZb

[meowsbits]

Thanks for your feedback!

edge of eternity attack

:joy: I "invented" this term to describe cases of (even semi-...)permanent bifurcation caused by n vs. n-1 (or otherwise "close") state discrepancies, with adversaries targeting that "edge" to force one set to an "eternal" disagreement.

And the variable-hashpower balancing strategy is indeed among the most significant risks I see, though given the degree of random variance in honest hashpower it seems like the attacker would have at least a non-trivial challenge.

floats in the consensus-layer spec definition

You're right -- integers to the rescue! This issue hadn't occurred to me as a critical one because the algorithm's "weak"ness permits marginally inexact gravity measurements (anticipating variances in last-known state anyways). With that said, though, I think it would be worth refactoring for nice round numbers (and protocol consistency), and your cubic looks fine to me.

[realcodywburns]

block times over the last ~2 million blocks is 59 seconds

The last 2 million have been boring. I was thinking of the dao split times. The head staleness check was what i was talking about and would require an incredibly unlikely heist to accomplish(but this is blockchain).

I was imagining a longer term, more coordinated attack where an adversary spent some time mining honestly with >2/3 the total network hash to increase the total difficult. At the time they choose, they could remove miners from mainnet (leaving it with a difficulty that would be near impossible for 1/3 the hash rate) and produce the reorged chain. Since the honest miners would take longer to produce a block than usual than, the staleness check would default to the reorg chain.

That being said, It is extremely unlikely that it would be possible unless the attacker was Danny Ocean. MESS will solve the problem it sets out to accomplish.

If were adopting it as a 'best practice', I think you should make the assertion of the general principle first. It has been a missed opportunity in the past or we just assumed it was implied by adoption. Accepting an improvement proposal means that the community accepts the idea as a core value;

• limited supply(monetary policy),
  • no forced changes(bomb removal),
  • gas cost shouldn't be abused (gas cost changes for IO-heavy operations) ((this one needs to be revisited aka gastoken))
  • feature parallel to eth for tooling is desired(recent forks)
  • contracts should comply to standards(status codes)

It should be silly that anyone would assert that etc doesn't have or know its "core values" since that the purpose of ecips are clarifying these values.

also +1 for integer math. Floats are slow w/o a real benefit

[ghost]

When you have the lead core developer of the main client and the leading development company propose "weak subjectivity" in a blockchain, you know there is no hope for that system anymore...and it is a waste of time...

:-/

[vbuterin]

Isn't the core principle of this ECIP just protecting immutability of transactions?

Four years ago the main threat to immutability that the ETC community saw was off-chain coordinated state intervention forks. Today we're living in a different world and the main threat is 51% attacks. MESS protects immutability by ensuring that after some period of time majority-hashpower-driven reversions are impossible.

[q9f]

When you have the lead core developer of the main client and the leading development company propose "weak subjectivity" in a blockchain, you know there is no hope for that system anymore...and it is a waste of time...

What's your proposal?

We don't have to accept MESS but we should at least show some respect to the few engineers that are still willing to design and implement solutions for Classic.

Once exchanges start delisting ETC because 100k confirmations are unpractical, Classic will further go down in a death spiral. Creating proposals such as ECBP-1100 gives miners, pools, exchanges, and other service providers a way to quantify the risks they are taking by looking at the hashrate and estimating how viable attacks are and how high (or low) the min confirmation numbers should be.

MESS is one of the least invasive proposals we've seen to date and allows to reduce confirmation times for pools and exchanges.

[ghost]

Satoshi:

"It is strictly necessary that the longest chain is always considered the valid one. Nodes that were present may remember that one branch was there first and got replaced by another, but there would be no way for them to convince those who were not present of this. We can't have subfactions of nodes that cling to one branch that they think was first, others that saw another branch first, and others that joined later and never saw what happened. The CPU power proof-of-work vote must have the final say. The only way for everyone to stay on the same page is to believe that the longest chain is always the valid one, no matter what."

Cody:

"Maybe there is a need for an overarching 'core principle / best practice' : 'small reorgs are normal and healthy, large reorgs are suspicious. given a reorg of unusual length; nodes should evaluate the current chain head they have with preference over the incoming chain with longer length or higher difficulty' This would cover PG, MESS, and possibly checkpointing."

Vitalik:

"However, new nodes joining the network, and nodes that appear online after a very long time, would not have the consensus algorithm reliably protecting them. Fortunately, for them, the solution is simple: the first time they sign up, and every time they stay offline for a very very long time, they need only get a recent block hash from a friend, a blockchain explorer, or simply their software provider, and paste it into their blockchain client as a “checkpoint”. They will then be able to securely update their view of the current state from there."

Isaac, James, and Terry:

"What Cody and Vitalik say."

Fabio and the rest of Ethereum Classic NPCs:

"I just want number go up....yay!"

Common Sense:

¯_(ツ)_/¯

[meowsbits]

@TokenHash:

What other people say.

[ghost]

@meowsbits, at least the right other people.

Vitalik's case for weak subjectivity:

"[Bad Bitcoiners say] if the solution to long-range attacks is some alternative deciding mechanism X, then the security of the blockchain ultimately depends on X, and so the algorithm is in reality no more secure than using X directly..."

"[However, Bad Bitcoiners are wrong because] this logic ignores why consensus algorithms exist in the first place. Consensus is a social process, and human beings are fairly good at engaging in consensus on our own without any help from algorithms..."

Repeat:

"Consensus is a social process..."

"...human beings are fairly good at engaging in consensus..."

"...without any help from algorithms..."

Yeah! Brilliant! Hey, why don't we just use PayPal?

[meowsbits]

I just updated the proposal, check it out! https://github.com/ethereumclassic/ECIPs/pull/384

• Rel https://github.com/ethereumclassic/ECIPs/issues/374#issuecomment-691662459: https://github.com/meowsbits/ECIPs/blob/ecbp/mess-2/_specs/ecip-1100.md#general. Added more of a core principals section, hopefully tackling the call for establishing that as an important thing.
• Rel https://github.com/ethereumclassic/ECIPs/issues/374#issuecomment-694156719, https://github.com/meowsbits/ECIPs/blob/ecbp/mess-2/_specs/ecip-1100.md#proposed-additional-subjective-arbitration. Updates spec (and code) to use the polynomial function with big.Ints.
• Rel https://github.com/ethereumclassic/ECIPs/issues/374#issuecomment-694526936, https://github.com/meowsbits/ECIPs/blob/ecbp/mess-2/_specs/ecip-1100.md#implementation. Updates implementation and referenced spec using a 30*13second head staleness check to address the exploit detailed in the comment.
• Rel https://github.com/ethereumclassic/ECIPs/issues/374#issuecomment-695895813 and https://github.com/ethereumclassic/ECIPs/issues/374#issuecomment-696861041: https://github.com/meowsbits/ECIPs/blob/ecbp/mess-2/_specs/ecip-1100.md#the-case-and-place-of-subjectivity. Added a section about subjectivity for the hardcore code-is-law folks.

[etcvietnam68]

@meowsbits https://github.com/ethereumclassic/ECIPs/pull/384: moves tentative mainnet "activation" block number to 11377500 (ETA Wednesay, 29 September 2020) => In my calculation, with block number 11377500, mainnet will need more than 17 days to reach this block if block time is 14s. Is this correct date?

[q9f]

Recording of the presentation: https://www.crowdcast.io/e/mess-classic-ecbp-1100

[meowsbits]

@etcvietnam68 You're right! Great catch, thank you :pray: I'll fix this up right now. Will (again, tentatively, as a working number -- we're still finalizing things) aim for 11317400 (a week from today), which I calculated from current block 11270907, using 13s block times. I hope this one checks out! :blush:

>>> 11270907 + (7 * 24 * 60 * 60 / 13)

  11270907 + 7 × 24 × 60 × (60 / 13)

   = 11317400

[etcvietnam68]

@meowsbits You're welcome, bro! 😉

[meowsbits]

Just an update, we've decided to not make a decision about an official mainnet number yet, but have set the Mordor testnet to

        ECBP1100FBlock:     big.NewInt(2380000), // ETA 29 Sept 2020, ~1500 UTC

A Core-Geth release will be following shortly.

[SergioDemianLerner]

I think the proposal is broken regarding the following attack: Mallory, a malicious miner (the attacker), starts mining private blocks starting from a height (x+1) where the block at height x is a common parent, but she sets her blocks timestamps for height y>x as timestamp(x)+(y-x). All the timestamps of the attacker's blocks are 1 second apart. The difficulty in the attacker's chain increases, but this is not a problem: the attacker's blockchain will have a lower number of blocks than the honest chain, but it doesn't change the amount of hashrate the attacker needs.

Therefore the attacker makes the timestamp protection in MESS 10 times less effective.

To fix this, a new rule has to be added (the rule originally described in the context of my ECIP-1096 proposal): A best chain MUST end in the current time (minus some fixed constant, such as 5 minutes). Let's call it the "availability" rule. A chain with higher cumulative difficulty that ends in the past should not be selected as the best chain.
By doing so, the attacker must at at least one block with the current time at the end and MESS will correctly score the attacker's chain.
The "availability" rule has consequences: a node that is unable to synchronize with the miners but is trapped in a partition will not be able to confirm new transactions in block received by peers, even if they are past blocks. This is, as I see it, something good.

Please check if I overlooked something in my analysis of MESS.

[meowsbits]

Good thinking! (And an interesting solution ;))

While indeed the original function used the proposed time offset, we've somewhat recently changed to using current.Time instead, and for this very reason. The spec was updated to his recently, here.

Do you see any issues similar or otherwise with this?

[SergioDemianLerner]

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]

Note that even if the network cannot stop the attack by protocol, the attack becomes public during the first phase. The community could react and try to pause the network and all exchanges.

[meowsbits]

This scenario seems related to the one considered at https://github.com/ethereumclassic/ECIPs/issues/374#issuecomment-694526936.

We have also considered using segment length (by block count) as the domain. Any thoughts on that?

[q9f]

We have an active MESS node on Mordor now if anyone wants to test. (Block 2_380_000) happened a couple of minutes ago. Release for testing:

• https://github.com/etclabscore/core-geth/releases/tag/v1.11.14

Monitoring:

• https://mordor.dash.fault.dev/
• https://mordor.fork.fault.dev/

[lirazsiri]

I am not sure understand the tradeoffs correctly. Does MESS reduce the global (e.g affecting all participants) vulnerability to attackers with temporary access to hash power at the expense of increasing local vulnerability (e.g affecting a single participant) to attackers that can manipulate network traffic and successfully bifurcate victims from the Internet?

In other words, what effect would MESS have on the total hash power needed for the attacker to appear as the preferred chain for a particular victim or subset of victims, assuming the attacker can eclipse them at will?

[lirazsiri]

Since the proposed gravity is a wave function, does this imply that at some point the total hash power needed for a reorg returns to baseline? If so how long would an attacker with more than 51% of hash power need to secretly mine the competing chain?

[meowsbits]

In other words, what effect would MESS have on the total hash power needed for the attacker to appear as the preferred chain for a particular victim or subset of victims, assuming the attacker can eclipse them at will?

If the attacker can eclipse anyone at will, they don't need much hash power at all, since the victim(s) will never see the honest chain. This is the same with or without MESS.

Does MESS reduce the global (e.g affecting all participants) vulnerability to attackers with temporary access to hash power at the expense of increasing local vulnerability (e.g affecting a single participant)

Yes, MESS exacerbates the symptoms of the eclipse attack upon the conclusion the attack. Instead of immediately recovering to the honest chain, the victim(s) will require that the honest chain has 31x+ total difficulty over their local segment, which is the segment the attacker has fed them. It should be noted, however, that this demand establishes a minimum value for the attacker's segment which is greater than it would otherwise be.

Since the proposed gravity is a wave function,

It isn't a wave function. The ceiling plateaus.

[ghost]

I see MESS is already "Active" and is a "best practice", in other words, optional for some nodes and miners to use. However, I have some comments:

• As @SergioDemianLerner is showing there may be unknown attack vector when gadgets that seem simple start to be added to the network. The solution of the solution may turn into a complexity snowball scenario.

• MESS is a change in the consensus mechanism, although engineers don't see it that way because of how it is activated or segregated from the core code. But when an incoming reorg is rejected, and that rejection can be exercised by a subset of network nodes and miners, and the rest of non-MESS nodes are induced to follow that subset, we have a completely different network and consensus mechanism. That is not ETC nor Nakamoto consensus.

• I understand that MESS is being used as a "temporary" solution to a specific "low hash rate" problem of ETC, and am willing to live with it if limited in time as I wrote on https://github.com/ethereumclassic/ECIPs/pull/387 but I think it is important to acknowledge that Nakamoto consensus is being bypassed here, however temporary, and it doesn't matter that while there is no attack the network is mimicking Nakamoto consensus, that is just proof of work theatre.

• Potential economic consequences of MESS as a "temporary" solution:

• That it becomes a permanent crutch if hash rate never picks up

• That the subset of nodes and miners who use MESS become the de facto central controllers of the network

• That if a subset of nodes have the ability to mark what is the good chain for present and new joining nodes, why pay miners to spend energy in hashing blocks?

• The above applies to proof of stake as well

• If there are partition attacks, how are the splits resolved? With a phone call?

• If a subset of nodes and miners tell the rest of the world which is the good chain, what stops them from becoming the bad guys? In that case, how do the "honest" nodes solve that? With a Zoom call?

[lirazsiri]

In other words, what effect would MESS have on the total hash power needed for the attacker to appear as the preferred chain for a particular victim or subset of victims, assuming the attacker can eclipse them at will?

If the attacker can eclipse anyone at will, they don't need much hash power at all, since the victim(s) will never see the honest chain. This is the same with or without MESS.

If a victim is eclipsed forever then that's right, but if the victim can be eclipsed for a shorter time span (I.e for a few days) then MESS changes the amount of hash power required by the attacker to keep the victim from reorging back to the honest chain right?

In other words:

Scenario A: Without MESS attacker that eclipses an exchange needs X hash power to control which chain the exchange sees as the real chain.

Scenario B: with MESS the attacker that eclipses the exchange needs Y hash power on a decreasing slope up to 1/31 of the global consensus chain?

Does MESS reduce the global (e.g affecting all participants) vulnerability to attackers with temporary access to hash power at the expense of increasing local vulnerability (e.g affecting a single participant)

Yes, MESS exacerbates the symptoms of the eclipse attack upon the conclusion the attack. Instead of immediately recovering to the honest chain, the victim(s) will require that the honest chain has 31x+ total difficulty over their local segment, which is the segment the attacker has fed them.

For how long would an exchange need to be eclipsed to reduce the hash power required by an attacker feeding a dishonest chain to an exchange to 1/31 of the honest chain?

2) It should be noted, however, that this demand establishes a minimum value for the attacker's segment which is greater than it would otherwise be.

I don't understand. Could you please elaborate a bit? Thanks!

Since the proposed gravity is a wave function,

It isn't a wave function. The ceiling plateaus.

Got it thanks. So after the plateau the local chain is preferred over other chains as long as it has 1/31 of the hashing power?

[lirazsiri]

Maybe slightly off topic but has anyone explored weakening the subjectivity by weighing down blocks that have been checkpointed on other PoW chains like Bitcoin?

This would further weaken the weak subjective preference as preferring the heaviest ETC chain that was checkpointed on the heaviest Bitcoin chain first, leveraging Bitcoin objectivity . We could still have a MESS like weak subjective rule for blocks that haven't been checkpointed, but we would set up the weakest subjectivity rule to be weaker.

I've seen a discussion about this being considered with A BFT scheme of trusted signers. I was thinking more along the lines of the the protocol providing a small accumulating bounty that could be withdrawn by a miner that can prove their checkpointing transaction received N confirmations (e.g 6 on Bitcoin). A back of the envelope calculation is that it would only take about 1-2% of the current ETC block rewards to provide sufficient incentive to have least one ETC checkpoint in every Bitcoin block, though that might be overkill.

[phyro]

I have a concern regarding the opt-in/opt-out property of MESS.

Assumption 1: Some of the nodes will follow MESS logic, some won't => some of the exchanges will follow MESS logic, some won't.

Since the proposal allows people to choose, it means that there can be a temporary divergence of reality. The nodes that will be following MESS won't switch when a 51% attack happens and those that won't be following the MESS logic will reorg. We assume that the nodes will eventually converge to the same reality which will likely be the reality that MESS nodes see.

If the majority of miners don't follow MESS logic, then the attacker chain will survive. MESS only makes sense when the miners continue the chain they think is the honest chain.

Assumption 2: The majority of miners will be following MESS logic.

Now let's assume we have a set of exchanges S that don't follow the MESS logic. Let's observe what happens if an attacker creates a 5000 block reorg without a double spend and continues to mine for some time. Exchanges in S will reorg these blocks and be on the attacker chain. They all seem fine now, but there is a big problem because if the assumption 2. is correct, then they will get reorged back after some time. This in turn means that users on every exchange could be doing double spending attacks in parallel without even knowing. When the MESS chain eventually overcomes the non-MESS and a reorg happens, then I suspect that every exchange in S can be double spent by their users.

This is possible because we are now allowing a temporary disagreement of reality. Nodes should at all times try to look at the same state otherwise we get a lot of weird "sync problems" that are hard to reason about. You could have "opportunists" checking which exchanges don't have MESS which are checking whether there's an ongoing 51% reorg and then do a double spend for free. Exchanges MUST follow MESS if the miners follow it or they all open themselves to at least this attack.

It's possible that I missed something or that any of the assumptions I made are incorrect, but I do want to share a case I think is possible and very dangerous.

[bobsummerwill]

I am sorry to say that we have had to abort implementation of MESS within the Besu client.

1. The specification is largely defined using code snippets from Core-Geth, rather than being a free-standing specification.
2. Given that Core-Geth's code really is the specification, we would end up having to implement the same logic in Besu with bug-for-bug behaviour.
3. All of that Core-Geth code is LGPL-encumbered. Besu implementation from that code would be considered a derived work which is also subject to LGPL licensing. That is unacceptable for Besu which has permissive Apache 2.0 licensing.
4. There is no test-suite defined.

Further, MESS has already been deployed and will be active on ETC mainnet imminently. Even if the licensing and test-suite issues above were later resolved and MESS support was subsequently added to Besu, we would have to hope that nothing much changed based on multi-client implementation and multi-client testing of MESS, because the feature is already live. Changing behaviour after the fact could be very messy.

The same problems stand for Mantis, which is also Apache 2.0 licensed.

Given that most (all?) mining nodes are Core-Geth, the lack of MESS support in Besu might not make much practical difference. If the Core-Geth nodes with MESS support successfully defend against 51% attacks, the Besu nodes would be eventually consistent, along with non-MESS Core-Geth nodes.

[meowsbits]

I could easily remove the snippets taken from Core-Geth. I would be happy to replicate their logic in any other programming language. Would Latex make it feel more “free-standing”?

I had no idea that work was anywhere near started for Besu, and would be happy to share and help build and shape tests too. This is the first practical complaint of their absence I am aware of.

[meowsbits]

I've just made a PR including 13 cross-client tests: https://github.com/ethereumclassic/ECIPs/pull/391.

[meowsbits]

It has also occurred to me that I am the author of both the specification and implementation. As such, I'm happy to tell you that your critical assumption "Core-Geth's code really is the specification," which is the basis of points 1-3, is actually backwards. The Core-Geth implementation is derivative of the specification. As such, the specification's license (Apache 2) may be safely applied.

If you find the quotations of Core-Geth code in the specification -- which are intended for use as illustrative and exemplary purposes only -- problematic from a licensing level, please file an issue at this repository documenting the concern and describing the rationale. Provided a valid and sufficiently documented argument to that concern, I would be more than happy to remove or modify those citations as needed.

NB re: Core-Geth use of specification ideas and snippets: Apache 2 allows for use by GPL3 works.

[stevanlohja]

Is the ETC network "mess enabled" as of Oct 19 or until majority of nodes have mess enabled? If it's not, "mess enabled", then wouldn't 500 - 1000 confirmations be insecure right now?

[meowsbits]

MESS's efficacy for "non-suspicious" (ie first-appearing) network state growth depends miner adoption. For a guesstimate of adoption rates by client versions I would point you to https://etcnodes.org/.

[Soteria-Smart-Contracts]

So to clarify, not all nodes have MESS enabled. Is it enabled as default on CoreGeth, and how can we see the total number of nodes on which MESS is running? In order for the MESS ECIP to function properly, I assume it must be enabled on >50% of nodes.

[bobsummerwill]

@Soteria-Smart-Contracts You cannot identify whether or not Any given node instance as running MESS. But it is the default setting for core Geth and is likely enabled on close to 100% of nodes