Core Devs Call: Mining Algorithm Upgrade

[soc1c]

ETC Core Devs Call - Mining Algorithm Upgrade

When: Thursday, November 21, 2019, 1pm UTC, 60 minutes max.

Where: Ethereum Classic Discord https://discord.gg/dwxb6nf #ecips channel. Will use/create a voice channel ad hoc.

Agenda

• Quick client teams check-in
  • Parity Ethereum / Parity Tech
  • Geth Classic / ChainSafe, ETC Labs Core
  • Multi-Geth / Multi-Geth, ETCLabs Core
  • Hyperledger Besu / ChainSafe, PegaSys
• Defining a process
  • keeping the call technical?
  • ECBP-1076 "algo change process" ref ECBP-1076: Mining algorithm change process #187
• Discuss options for mining algorithms
  • ECIP-1049 "SHA-3" @p3c-bot ref ECIP-1049: Change the ETC Proof of Work Algorithm to Keccak256 #8 ECIP-1049: Change the ETC Proof of Work Algorithm to Keccak-256 #13
  • ECIP-1070 "ProgPOW" @YazzyYaz ref ECIP-1070: ProgPoW for ETC #171 ECIP-1070: ProgPoW for ETC Discussions #172
  • Status Quo: "Ethash" ...
• Agree on a joint way forward on the three proposals above
• Commit to a timeline
• Focus on a testnet
• Discuss anything else related to Mining
• Bonus:
  • ECIP-1043 "DAG Size Limit" @realcodywburns @Wolf-Linzhi ref ECIP-1043: Fixed DAG limit restriction #11 ECIP 1043: Fix DAG limit restriction #138
  • ECIP-1047 "Block Gas Limit" @pyskell @zmitton ref ECIP-1047: Reduce Gas Limit to 1 Million #6 ECIP-1047: Reduce Gas Limit to 1 Million #14

Please comment to add items to the agenda

[bobsummerwill]

We need to discuss gaslimit too:

@pyskell has submitted this proposal - https://ecips.ethereumclassic.org/ECIPs/ecip-1047.
@zmitton has indicated he has an alternative
And I will create an alternative ECIP as well.

I would argue that gaslimit and DAG are more important to tackle first, and algorithm options second.

The gaslimit and DAG are immediate issues with the current setup.

[ghost]

"Agree on a joint way forward on the four proposals above"

meaning, that "status quo" is also a way forward

[soc1c]

Updated agenda

[bobsummerwill]

Yes, @tokenhash.

I would suggest:

BLOCK 1:

• Status quo on gas, or impose gas limit
• Status quo on DAG, or introduce DAG size limit

BLOCK 2:

• Status quo on Ethash, or SHA3 or ProgPOW

Another radical option which we should put on the table in BLOCK 2 is reverting to "One CPU One Vote" using RandomX from Monero, and maybe there are other options. I don't think that is a good choice myself, because it would likely impact security horribly, but that is a "fair market" approach. Better for decentralization, worse for security.

Any of these transitions are "central planning", but might be the best thing for ETC if they lead to long-term stability. Same as the Monetary Policy.

But, IMHO, we should be aiming to set policy here to something we think can stick for decades, and then we lock things down BEFORE THE MASSES ARRIVE.

[bobsummerwill]

Also, the thing you hate :-)

https://ethereumclassic.org/blog/2019-10-06-pow-mining-explicit-social-contract/

So is this proposal a Constitution? Not really. It would just consist of a single sentence. Something like:

“Adoption of this proposal by the ECIP authors is an explicit social contact between the Ethereum Classic ecosystem and the POW mining ecosystem that ETC intends to stay with POW mining (not merged mining) into the indefinite future.”

[bobsummerwill]

That one-liner would probably be its own ECIP.
To be adopted or rejected.
Just as we are doing with ProgPOW.
Let me create an ECIP for that too.

I would advocate for that in BLOCK 1, because it applies whatever the hash algorithm is, and, like the gaslimit and DAG points is related to long-term certainty for miners.

[bobsummerwill]

It is kind of the opposite to creating an ECIP proposing a transition to POS and then rejecting it.

[BelfordZ]

Im going to post my comment from the sha3 ecip discussion issue:
#13 (comment)

[IstoraMandiri]

Wanted to mention an idea for switching algos inspired by grin.

Instead of having one specific block to do an instant switch, which could have weird economic, security and centralization implications (especially if miners are developing ASICs in secret waiting for a 'new algo switch block'), it might be safer to do a gradual switch over the course of X blocks.

For example;

• 10/10 blocks Ethash (now)
• initialize algo change
• 9/10 block Ethash, 1/10 blocks SHA3 (for 100,000 blocks)
• 8/10 block Ethash, 2/10 blocks SHA3 (for 100,000 blocks)
• ...
• 1/10 block Ethash, 9/10 blocks SHA3 (for 100,000 blocks)
• algo switch complete (total 1M blocks)
• 10/10 blocks SHA3 (going forward)

I assume this is probably more complicated to implement, but it provides some safety features (and gives time to fork if something goes wrong with the new algorithm)

[soc1c]

I assume this is probably more complicated to implement

Unfortunately, this is true. However, you could reduce complexity by allowing both - an Ethash proof and a SHA3 proof - as valid block hash for a certain range of blocks without defining a ration.

In general, switching a consensus engine is unprecedented for EVM based chains as far as I know and all clients that have to implement it, would require some substantial work.

[stevanlohja]

Rejecting Sha3 for the following reason posted on the Sha3 ECIP #13 (comment)

[developerkevin]

My opinion is to consider and prioritize the essential (needed, time sensitive) before the non-essential (desired, wanted, not time sensitive) changes to the network. In general, my view about adding changes via hard fork is do it as least as necessary.

My priority of changes.

1. Keep Ethash (for now) - my opinion is to keep it as is.

2. Restrict DAG Limit (ECIP-1043) DAG limit was used to incentivize miners to stop mining on ethereum. Just like the "Difficulty Bomb" removal to continue PoW mining or ETC miners, ECIP-1043 is the same. ETC must retain as many miners as possible and removing this limit should have been considered years ago. The larger the DAG gets the more miners will leave the network. We need more not less.

• Linzhi ECIP-1043 PR: Provided data points, risk considerations, implementation options, references

3. Gas Limit (ECIP-1047) (or via soft fork @pyskell)

• Info on Gas-Limit by MyEtherPlan

4. SHA3 Implementation SHA3 is objectively better than Ethash, and if I were designing ETC from scratch I would implement it no question, but this late in the game I don't think is the right time to make such a change, (yet?) . I think this change could have a place in ETC's future. In my opinion, there's just more important changes to be completed before forcing desired features on the network.

5. ProgPoW - Hell No

[soc1c]

please review before the next call

• ecbp-1076: mining algorithm change process ECBP-1076: Mining algorithm change process #187

I want to propose keeping the call on a technical level and adhere to a strictly defined, neutral, and open process. ecbp-1076 is what I believe our best shot.

[soc1c]

Starting in 30 minutes.

[soc1c]

Attendees

• BTCLovera
• Bwana
• Classic_Kevin_IOHK
• Craig[Bot]
• donsyang
• foenix
• GregTheGreek
• isaac
• Kimi Sian-Yu Chen
• Liz
• mikers
• MikO
• OmniEdge
• Roy Zou
• soc1c
• sorpaas
• stev
• Tj
• tzdybal
• wolf_li
• yaz
• Yebisu
• zacmitton
• zcstarr

Client team checked in

• ChainSafe
• ETCLabs Core
• Multi-Geth

ECIP-1076 "ECBP" mining change process?

• Alex: can we add testnet stage?
• Afri: gives ECBP 1076 Overview
• Tomek: only miners decision, is that good?
• Zac: agrees with Tomek
• Terry: Has this been used before?
• Zac: Yes, all Bitcoin softforks
• Problem: this is a hardfork not a softfork
• Alex: But 51% attack can manipulate the signal
• Greg: We did no analysis on client performance
• Afri: increase block range to mitigate 51% attack
• Alex: Core devs should provide defaults
• Zac: agrees, security benefits
• Alex: miners might be invested in certain interests
• Isaac: supports miner voting, proposes 5 million block range?
• Isaac: miners not only service providers, rather the life blood in this space
• Afri: not programmatically enforced but we should stick to the process
• Yaz: Extradata is a good way of signaling
• Kevin: What's our timeline?
• Afri: 5 million blocks are ~ 2 years
• Kevin: asks for delay
• Afri: is confused
• Zac: Do we have rough consensus on miner signaling?
• Bwana: Problem is clearly the decision stage. Signal yes, but not have this binding trigger.
• Afri: proposes to just use the signal and not commit to the binding decision.
• Zac: 5 years is too much
• Afri: proposes 6 months - 1 million blocks
• **rough consensus on the ECBP without binding decision trigger and longer signaling range (1m blocks?)

ECIP-1070: ProgPOW

• Yaz: let's reject it
• Greg: let's not jump conclusion
• Greg: upstream clients have it, so we should consider it at least
• Alex: ProgPOW has to be continously tweaked, enormouse security hole
• Greg: but what about Asic resistance?
• Alex: but the quality of the SHA-3 hashing algorithm, disagree with Asic resistance
• Yaz: ProgPOW Asic is easily possible
• Zac: ProgPOW is cool but not for blockchain, we dont want to tweak this over and over again
• Afri: does anyone really want ProgPOW? does anyone disagree with rejecting it?
• Greg disagrees
• Alex: someone has to champion it then
• Yaz: we should send a clear signal to ETH and reject it
• Wei: But we should have an open process to allow it in future
• rough consensus to reject it but open to put it back in draft if someone champions it

ECIP-1049: Keccak-256

• Alex: introduction and motivation on SHA-3
• Wei: has reservations, SHA-3 needs some work done
• Wei: good way of liberation, high performant
• Alex: we want Asics on the network
• Wei: we should have Asics first
• Tomek: without Asics we don't know efficiency, security concerns
• Zac: we won't get Asics unless we change the algorithm
• Mike: GPU and FPGA performance for SHA3 is very good and energy efficient
• Terry: technical benefits are not clear enough to do such a drastic change
• Alex: What's not clear, security or benefits?
• Stev: we need more research and data, how can we be sure not being 51% attacked
• Yaz: consider security of Nakamoto consensus
• Yaz: Ethash was just designed for Ethereum to sustain ETH till PoS
• Afri: states his opinion
• no conclusion yet
• next call to be announced for the remaining decisions (probably Jan/2020)

[zmitton]

@soc1c I think we have agreed to go forward with your 1076 process. The issue I see now (with the process), is that we now need approval of all the contentious EIPs before we can even move forward with this one (as defined in the "tech stage" section).

Since we have agreed not to make activation automatic, I think we should make the small adjustment that we do steps 1 and 2 in parallel. This will also allow miners a longer time period for signaling.

[soc1c]

@zmitton that's how I understood this. I will update the ECBP accordingly.

[sorpaas]

Regarding signaling -- I don't think we even have any "rough consensus" of ECBP-1076 yet. There're several alternative proposals, which IMO is much better in many retrospective in terms of automation and process. For example, ECIP-1022 https://ecips.ethereumclassic.org/ECIPs/ecip-1022 and 36-STATEVOTE https://specs.that.world/36-statevote/
There're also many unresolved issues -- for example, even if we go all in for MINERVOTE, there's still the issue that the vote signaling will always be using the old mining algorithm, which is, in some sense, biased.

[sorpaas]

@zmitton @soc1c I disagree. I don't think we can move forward with 1076 at all, for reasons stated above.

[soc1c]

the decision was made. please review #194

it's only an ECBP and the results are non-binding.

[sorpaas]

@soc1c The decision was not made properly at all. In all sense, it's rushed. Currently there's no reason to move forward with ECBP-1076 at all.

[zmitton]

@sorpaas did you not mention any of that on the call

[sorpaas]

@zmitton I wasn't available for the call in the first 45 minutes.

Let's put aside the issue that the decision was most likely interpreted and framed incorrectly by Afri. Consider, would you be really sure that you want to put forward a decision just because someone who has objections wasn't on the call?

In an imaginary scenario, Afri or other meeting moderators can arrange a meeting to move ProgPoW forward, and put the date/time of the meeting specifically that none of the ProgPoW opponents could attend. Then the decision of adopting ProgPoW can be easily reached. Would you move forward with ProgPoW just because of that? No. The same applies to 1076.

[zmitton]

• we had a call
• @sorpaas was on the call
• none of the above objections were raised on the call
• the proposal is process only (not pertaining to consensus or fork)

That's "properly" from any reasonable interpretation. Raising a concern after everyone has disbursed is however, not proper.

This proposal is itself a very watered down compromise to the actual options at hand (the first of which was proposed already 1 full year ago).

[sorpaas]

• We had a call but the call was rushed, and the moderator tried to frame the discussion improperly.
• @sorpaas wasn't on the call when 1076 was discussed.
• None of the objections were raised on the call because everyone who said objections weren't present, not only me. Those objections, however, can be clearly seen in Github issues and PRs.
• The proposal is regarding an non-ECIP process only so there's no point in rushing it forward. Afri and you can just carry it out or whatever. You don't need "community's permission".

The logic you're presenting is improper. The goal for a meeting is to determine the rough consensus, and the process of the meeting should be designed as such. If the meeting failed to determine the rough consensus or the process was tricked to push forward personal agendas by some people, then we should reflect on whether we can improve the process.

If you want to play politics, go find some other coins who are happy to play politics with you. In Ethereum Classic, we should aim at adopting the proposal with the best technical merits.

[q9f]

continued in #333