ECBP-1076: Mining algorithm change process

[soc1c]

This meta document is agnostic to any mining algorithm. Its sole purpose is specifying a process how to openly determine and select a mining algorithm for Ethereum Classic.

ref #174

[bobsummerwill]

My primary objection to this process as stated is that it puts the decision-making on change of mining algorithm purely in the hands of the miners.

They are not the only stakeholders and should not be the ones making that decision. Yes, miners need their voice, but other stakeholders need their voice too.

Miners will vote in their own interests, which do not necessarily coincide with the needs of the network. Gaslimit voting for ETH1 is a primary example of this, where gaslimit has been voted beyond the limits of the client software to cope - resulting is massive centralization.

There is no counter-balance there, and there is no counter-balance here.

[soc1c]

this is a draft. please add as many steps to the process as you wish

[phyro]

I agree with @bobsummerwill . This kind of voting/signaling has the same incentive flaw as the DAO carbon vote. Miners are incentivized to optimize for themselves in a similar way that the DAO token holders were incentivized to bail themselves out.
The nice thing about this is that it is automated though. I don't know of any better automated way tbh.

[soc1c]

I will champion this proposal unless you come up with a better idea. And I am open for suggestions or adding additional signals.

Nobody wants to spend tens of hours on calls.

[sorpaas]

ECBP-1076 is basically MINERVOTE. But TBH, if we're going to the route of letting miners decide PoW algorithm change, then I'd suggest we do something more sophisticated, such as 27-MINERVOTE, rather than ad hoc process that still involves human factors. https://specs.that.world/27-minervote/

If you are a miner, I would guess the most important thing you want to review are:

• Voting range: in ECBP-1076 this is unspecified (?). In 27-MINERVOTE this is a known recurrence period, usually several weeks to a month.
• Activation time: in ECBP-1076 this is 6 months (!). In 27-MINERVOTE this is again, usually several weeks to a month.
• Threshold: in ECBP-1076 this is 70%, meaning there may be still 30% of the miners against a particular algorithm change. In 27-MINERVOTE we don't have a fixed number, but for things controversial like this we may want a higher threshold, such as 90%.

[soc1c]

Thanks for the feedback.

• The voting range is indefinite. Any block that reachs the threshold should be considered as threshold block. Happy to talk about a sensible range though, I just cannot imagine any, yet.
• It's six months because the change is substantial and we need all clients to implement it. You cannot switch to Keccak256 in a couple of weeks.
• It makes sense to bump this to 90% if it appears to be controversial. However, this would mean that Ethash ASIC producers only need 10% of the ETC hashrate to ensure a change will never happen. It might be sensible to go with 70%.

[mikeyb]

and anyone else who feels having a stake in ETC
Should this be?
and anyone else who feels they have a stake in ETC

[mikeyb]

are encouraged to utilized
Should be ?
are encouraged to utilize

[zmitton]

Suggested change

	The following process facilitates all stakeholders in various stages.
	The following process facilitates all stakeholders in various stages, with "Tech Stage" and the "Miner Stage" to occur in parallel:

[zmitton]

Suggested change

	2. _"Miner Stage."_ Solo miners, mining farms, and mining pools can signal support by adjusting their mining node to signal in favor of one of the proposals that was promoted to "Last Call" state in the previous stage. Details on the signaling can be found in the subsequent section.
	2. _"Miner Stage."_ Solo miners, mining farms, and mining pools can signal support by adjusting their mining node to signal in favor of one of the proposals specified here. Details on the signaling can be found in the subsequent section.

[soc1c]

@zmitton can you review #194 instead?