ECIP-1022: Generalized Version Bits Voting for Consensus Soft and Hard Fork

[sorpaas]

(Rendered)

See also ECIP-1023.

This tries to bring the best practices about how Bitcoin deals with consensus hard fork (BIP-9 and BIP-135) into Ethereum Classic. Rather than hard-code a block number as we currently do, each block mined emits support of the new consensus hard-fork. Only when a large enough portion of the network support it, the hard-fork is "locked-in" and will be activated.

Note that this ECIP should be considered informational and will not take any effect (even when its status becomes active) unless other consensus hard fork ECIPs decide to use this.

Motivation

Lack of an appropriate voting method can results in network forking. The DAO hard fork was such an example. Currently the way Ethereum used to gather opinions was through CarbonVote. It indeed has the advantage that it brings the opinions of Ethereum holders rather than miners. However, it is not enforceable and we all know the disastrous result it brought during the DAO hard fork period. We don't want that to happen again.

Miner community, stake holders and proof of work. It is common knowledge that Ethereum Classic will probably stay in proof of work, rather than, like Ethereum, switch to a proof of stake algorithm. Combining this ECIP together with ECIP-1023, we combines opinions from both the miner community and ETC coin holders to reach consensus about whether a hard fork should occur.

Best practices from Bitcoin. BIP-9, which uses version bits mined in each blocks to vote for consensus soft fork has be successfully conducted for several. Its upgraded version, BIP-135, aims to deal with both soft forks and hard forks alike.

Potentially faster adoption of new consensus hard fork. When dealing with emergency consensus hard fork for preventing network attacks, the developer would not need to artificially insert a "hard fork block number" (which must leave enough time for everyone else to upgrade their clients, and then wait for that block). The ETC coin holders and miners collectively decide when the hard fork happens, which potentially could be faster than hard coded block numbers.

Ethereum Classic will become a stable protocol soon. When we finished dealing with the monetary policy and finally the difficulty bomb, ETC's protocol would become a rather stable one. This means most of the new consensus hard fork would be new features of the network, rather than fixing existing bugs. In that case, voting would be important to keep the whole network healthy.

Implementation

See the rendered ECIP for the actual specification. The major difference to BIP-135 is that instead of using nVersion with raw bits, we use a RLP list representation with version 1 using the extraData block field.

Another difference is that we don't use any notion of seconds to calculation passed time, as this requires MTP, which complicates implementing ECIP-1022. All time passed calculation (for starting to signal a fork, during the voting period, and during locked-in before activation) uses solely block numbers, as this seems to be the standard convention in the Ethereum world.

[elaineo]

What are your thoughts on using this in conjunction with, say, BIP 148? https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki

[sjmackenzie]

The DAO hard fork arose due to immaturity and greed, making short sighted patches based on immature greedy actions is never a good idea and can cause systems to become more brittle. Hardforks are not bad if they are handled in a responsible way which involves communication and mature minded people at the table. This has already been demonstrated with the monetary policy. The Goldilocks zone is to be more strict than Ethereum and less strict than bitcoin.

[sorpaas]

@elaineo Can you briefly explain what BIP-148 does? That docs looks somewhat confusing to me...

[elaineo]

@sorpaas In a typical soft fork, miners signal support and then activate, without consideration for the fully-validating nodes. BIP-148 proposes a user-activated soft fork where fully-validating nodes ignore non-activated blocks, which effectively blocks out the miners that don't activate.

[elaineo]

(we tend to think of miners as the rule enforcers, but really they just process transactions. If the network commits to ignoring invalid blocks, then all the hashpower in the world could not generate an invalid transaction)

[sorpaas]

@elaineo I'm open to discussion, but IMHO, I think UASF (a.k.a. BIP-148) is a little bit too disruptive -- it encourages network splits (with the side of UASF without enough hash power, if I understand this correctly). This sort of goes against our goals, which is to avoid another network split for Ethereum Classic again.

I think what Ethereum Classic and Bitcoin face different problems right now. For many Bitcoiners, whether to activate segwit is a life or death problem, but for us, hard forks from now on would more likely be new features that make the blockchain more convenient to use. So I think it would be better to seek majority agreement (from both miners and stake holders) rather that ignoring those who don't agree with us.

[elaineo]

@sorpaas Sure, I agree with that assessment of UASF. I doubt it is possible to find a one-size-fits-all hard-forking method. My understanding is that ECIP-1022 is a proposal for a signaling method, but the actual activation will be determined on a case-by-case basis. Is that correct?

[sorpaas]

@elaineo Yep, this ECIP (together with ECIP-1023) should only be considered informational.

Other ECIPs about consensus hard forks need to determine their own best way to reach agreement -- use a hardcoded block number, use ECIP-1022, use ECIP-1022 together with ECIP-1023, use a smart contract, or use another hard-forking method.

[elaineo]

FWIW bitcoin core considering moving away from BIP-9 signaling https://bitcoinmagazine.com/articles/lombrozo-bitcoin-core-developers-may-never-use-miner-focused-bip-9-signaling-again1/