ECIP-1092 51attack solution: PirlGuard & Callisto proposal

[Dexaran]

---

lang: en ecip: 1092 title: 51% attack solution: PirlGuard & Callisto status: Draft type: Core author: dexaran (@dexaran) created: 8/7/2020 license: LGPLv3

Abstract

The following describes a method of preventing a 51% attack on Ethash-based POW chains.

Motivation

Ethereum CLassic suffered a number of 51% attacks already. Here you can find an article from Cointelegraph describing the 51% attack on 6 Aug 2020. Here you can find another article describing the 51% attack on 10 Jan 2019. As long as ETC protocol remains unchanged it is susceptible for more 51% attacks.

Specification

The proposed solution refers to the PirlGuard protocol.

The description of the protocol states that instead of automatically syncing with any privately-mined chain branch the new protocol should require the peer proposing the privately-chain (and the reversal of the publicly mined and synced blocks) to mine a number of "penalty" blocks. The number of penalty blocks must depend on the number of the original blocks that would be reverted if the chain will reorganize and sync to the proposed (privately-mined) branch. Thus the cost of the 51% attack will dramatically increase as the attacker will not be able to mine his private branch and then broadcast it to the network thus reverting all the transactions from the "main" branch.

Rationale

This protocol is already implemented in Pirl and Callisto Network. The protocol has a working time tested reference implementation. The proposed change requires minimal modifications of the Ethereum CLassic protocol while offers a reliable method of protecting against the recent attacks and the relevant threat of newer similar attacks.

Implementations

Here is a reference implementation of the protocol in GO lang: https://github.com/EthereumCommonwealth/go-callisto/blob/master/core/pirl_guard.go

https://github.com/EthereumCommonwealth/go-callisto/blob/master/core/blockchain.go#L1540

Presentation

Made by @padenmoss

http://padenmoss.com/public/ECIP-1092_proposal.pdf

Copyright

This ECIP is licensed under GNU Lesser General Public License v3.0.

[wpwrak]

A formal specification would be 1) concise, 2) allow comparing its model against related specification, such as that of Ethash, 3) allow to precisely model the behaviour of the proposed change, and 4) allow verifying that implementations match the specification. Pirlguard comes with a) very high-level descriptions of the general idea, and b) a patch to an existing client.

a) means that there is far too much room for interpretation, and all the elementary steps (e.g., what information is present at what time, both in terms of state and in terms of data passed between clients, how exactly it is to be used, including how it affects state) are not clearly defined. b) in a way provides that detail, but puts it in the context of a complex implementation. So in order to understand what exactly that patch is doing, you need to i) be very familiar with the implementation of go-callisto, and ii) know the Go language. Worse, the pointer to the code is not even versioned, so you'd have to consider all past and future changes to any of the code not only in the Pirlguard extension but to go-callisto as a whole.

Basing specifications on implementations is inherently dangerous. Even if the implementation tries to be concise, you can quickly end up with code that doesn't work or that does not behave the way it was intended. This is especially true if you're using one of the "new" languages, that still change fairly frequently. As an example, consider the Ethash reference in Python, at https://eth.wiki/en/concepts/ethash/ethash It looks nice and concise, but if you try to run it, you'll find that it doesn't work, and you may find that it produces results that differ from what real Ethash does. For a runnable implementation that does produce correct results, see https://github.com/LinzhiChips/ethash-ecip1043/blob/master/ethash.py

go-callisto is a lot more code, so imagine all the things that you may have to consider there. Not because they would affect what Pirlguard does, but because you can't be sure that they don't unless you have checked them. That's why a specification should be concise and self-reliant. Also, for analysis, you usually want to make simulations. It's usually not too hard to make a model from a good specification, but it's very hard to turn some big implementation into a simulation. (Been there, done that, but while it was fun at the time, I would recommend putting the bar a little lower: http://umlsim.sourceforge.net/)

So, to summarize, the high-level description, a), fails to meet requirements 2, 3, and 4. The code b) fails to meet 1, 2, and 4 (with the exception of the implementation being go-callisto, or very similar to it), and makes 3 too difficult to be of practical use.

E.g., a good specification would first define the local state of the client, e.g., how the relevant part of the chain is represented there. That's also an opportunity to define all the terminology and concepts that will be used, such as head(s), distances, and so on. Then it would define the current operation of incorporating new blocks obtained from a peer, in the terms of this specification, and a low level of abstraction. Now you have a basis for presenting the modification: define any state that gets added (if needed), then define what incorporation of new blocks looks like then.

With such a specification, one could immediately analyze whether the algorithm is sensitive to the timing or partitioning of new blocks presented, whether state is affected by client resets, under what conditions clients may diverge for an undesirably long time, and so on.

If all that gets too long, you can also make a more compact specification that leaves our the underlying model, and reference a more detailed version. At least back when I was working with IETF specifications, that was common practice: the RFC stated the goals and provided the (patch-sized) core bits of the protocol/algorithm/etc., and then there were one or more papers with the underlying details and further analysis.

[padenmoss]

The behavior of this change has been modeled on the callisto network and a similar implementation has occurred on Horizen. What you are describing is a non-existent obstacle based on a demand for comparison via ethereum classic test nets. This is wholly unnecessary, indeed a waste of resources and man hours, due to the existing network which has already implemented these changes that can be accessed by utilizing callisto. Callisto is itself a fork of ethereum classic, which could be arguably seen as a testnet.

If you want to compare PirlGuard to MESS, then compare the callisto network and the mordor test network. The precise model you desire already exists in the Horizen implementation, with multiple studies conducted on the efficacy of these changes: https://github.com/anneouyang/horizen/blob/master/README.md

No write up or description is going to change the protocol from what is already described. If you wish for a comparison to a separate model, the burden is on you to describe the problem and test a solution. ECIP-1092 is a solution that is easily explained and incorporated quickly without wasting hours on test nets and developing a system similar to what has already been successfully integrated elsewhere.

None of what you describe is necessary. You voice what you would like and expect others to react when you do not put forth effort to answer your own questions. Stop wasting time.

[phyro]

I agree with @wpwrak. This isn't specific to PirlGuard though, this should be done for any serious change. I think any change to the core and especially the consensus should be shown secure either by proving it or by convincing people that the simplicity of the change and enough eyes will be good enough - even though the code change is 100 lines, it's far from clear to me what side-effects PirlGuard can cause to the system. In both cases, you need a framework to reason about the change and some sort of a formal spec is a great way to do that. If we don't do the research and keep introducing important changes that have very little research behind, we'll eventually make the network explode because we will miss new cases they introduce. Of course, since we're not the size of Bitcoin, we can't rely on having every change come from a peer reviewed research paper, but it needs at least a bit of rigor and some mathematical description. As was mentioned above, there needs to be some modeling of the state and description of the system variables that the change can affect. Dropping a .go file and saying "it works on a tiny network" is not sufficient in my opinion. I'm not a fan of any kind of subjectivity in the consensus, but if I compare MESS and PirlGuard proposals, there's a very big difference in the amount of work that was put into the ECIP and the analysis of the solution.

[padenmoss]

If you are interested in testing the security, why not attempt to break Callisto? The resources required to build a separate test network which includes PirlGuard would probably cost more than what would be required to test your proposed attack vector on Callisto.

What I see from both @phyro and @wpwrak is a lack of personal responsibility for your accusations. Neither of you are willing to put forth effort into creating a formal definitions of neither ECIP-1092 nor your criticisms of PirlGuard. All you have are speculation and requirements which you are unwilling to meet.

You say this code is not functional, yet you are unwilling to test it nor put your money where your mouth is and attack the Callisto Network.

Since you are unwilling/unable to prove the dysfunction of Callisto, I say we move ECIP-1092 forward unless detractors decide to quit being cheap cowards and break Callisto with their proposed attacks.

[wpwrak]

@padenmoss, you seem to mistake the concerns phyro and I are raising as some extravagant obstacles we put up due to some hostile attitude. Be assured that this is not the case. You are likely to encounter similar requests any time you propose changes of protocols that are used on a larger scale. The purpose of such requests is not to shoot down a proposal but to better understand it and to ensure it does not introduce new major issues.

Regarding effort, I offered two weeks ago on the ecip-1092-pirlguard channel to help with drafting such a specification. After one positive response, the rest were all negative.

I agree that a test net would be an unsuitable tool for such analysis. That's why we use models and simulations. Test networks are good for shaking out relatively easy to find implementation and interoperability issues, but simulations let you create precise conditions, reproduce experiments, and add whatever instrumentation you find useful. But before you can simulate, you need a model.

Thanks for the pointer to Horizen ! This is the first time I saw this mentioned. And yes, also a compact implementation in the constrained environment of a simulator could be a basis for a specification.

[stevanlohja]

Hey @Dexaran are you still active on this proposal? Please let us know in a few days otherwise this Issue could be closed or ECIP set to inactive.