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.

[BaikalMine]

Its a good idea!

[TheEnthusiasticAs]

From several days of discussions of this topic in the ETC discord, I summarized the pro and contra arguments, what I could collect:

Pros:

• a working solution on the Callisto Network
• Can be implemented like a "copy-paste"
• could be seen as a temporary solution till a better one is found

Contras:

• some developers have technical doubts till they see security report(s)
• it makes possible to have a chain with less PoW to win (PoW rule: a chain with the most PoW wins)
  -> violation of the censorship-resistance-principle (because one mined offline it will be penalized)
• some other blockchain principles would be broken, what one can't see at them moment
• an attacker is e.g. making 3k+ block reorgs. They have the time and money to check in and then mine 3k more honestly

Please extend/correct, if you have any suggestions!

[Dexaran]

some developers have technical doubts till they see security report(s)

How can "some developers" have technical doubts if there is a working solution that proves to be tested in the wild for long time already?

As a security auditor I can formally write a security report but it looks like an unnecessary encumbrance for the implementation that is already operational in various perfectly working networks.

[crazypool2019]

We need a prompt and timely solution, even if it is temporary, implementing this solution is the fastest we have, and we urgently need it

[BaikalMine]

We need a prompt and timely solution, even if it is temporary, implementing this solution is the fastest we have, and we urgently need it

I fully support! Without this decision, the coin will not live long.

[dinc334]

Expanse was attacked several times in 2019 (https://gist.github.com/metalicjames/01222049f95f85df8c0eb253de54848b)
And our lead developer @chrisfranko decided to implement PirlGuard, after that, we didn't have any problems. So, yea, ETC should add it as fas as they can and maybe later change it to custom solution.

[crazypool2019]

We need a prompt and timely solution, even if it is temporary, implementing this solution is the fastest we have, and we urgently need it

I fully support! Without this decision, the coin will not live long.

it's true, at this moment etc is a dead coin

[Sparke2]

ignorance of etc teams and community to the real problem in presence of a proposed solution is just awful
this damages reputation of etc project

[crazypool2019]

Dear ETC developers, please don't waste any more time, implement pirlguard once and for all

[Dexaran]

I would ask all the participants to provide a proper rationale for their opinions.
Please keep the discussion free from excessive comments. In order to make your voices counted you should switch to twitter and provide your requests there. In this case you can encourage even more parties to pay attention and react.

As for the github thread - I'd prefer to see more technical details and reasoned 'pros' and 'cons' of my proposal.

Thank you for understanding.

[dinc334]

Pros:

• working solution on EXP, PIRL, CLO
• easy to implement
• easy to understand

Contras:

• hardfork need
• not a native ETC solution
  Idk what to add more.

[phyro]

I could be misunderstanding the implementation so I apologize if that's the case. In case I'm wrong I'd appreciate if you explained to me why this would not be possible.

Let's forget about 51% attacks and say the attacker wants to split the network. The PenaltyCheckLength variable is set to 60 for all clients.

From this line we can see that if I make a reorg of 60 blocks, the if condition will be false and hence we will have no penalty which means the reorg will happen and the person will switch to the attacker chain.
So the victim will now have last 60 blocks different from the mainnet. The attacker now also adds 1 more more block to the victim chain (could also add 10 or whatever). When the mainnet mines 2 blocks, the mainnet chain will have more PoW and the victim client will want to reorg, but since it will try to reorg 62 blocks, it will get a huge penalty due to the int64(tipOfTheMainChain - incomingBlock) computation in a for loop for all reorged blocks that add to the penalty which means the victim chain will stay split for a long time.

If this is possible, then I could time these blocks in a way that roughly 1/3 or 1/2 of the network would receive them and become victims of a split. I could even make K splits if I made K different reorg chains and send them to different nodes.

[knocte]

IMHO, ETC is selling itself as a more conservative alternative to ETH: by keeping PoW, by not having infinite inflation (like the 1st blockchain: BTC). Deploying this would go completely against this narrative, because this looks like a very experimental thing (has any other blockchain adopted this?). Also, given that ETH is switching to PoS very soon, we might get a new influx of PoW miners on ETC chain, which would decrease the feasibility of more 51% attacks.