search

ethereumclassic / ECIPs

https://ecips.ethereumclassic.org
82 stars 62 forks source link

Core Devs Call: Mining Algorithm Upgrade #174

Closed soc1c closed 4 years ago

soc1c commented 4 years ago

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

Please comment to add items to the agenda

bobsummerwill commented 4 years ago

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 commented 4 years ago

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

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

soc1c commented 4 years ago

Updated agenda

bobsummerwill commented 4 years ago

Yes, @TokenHash.

I would suggest:

BLOCK 1:

BLOCK 2:

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

BelfordZ commented 4 years ago

Im going to post my comment from the sha3 ecip discussion issue: https://github.com/ethereumclassic/ECIPs/issues/13#issuecomment-551256069

IstoraMandiri commented 4 years ago

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;

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 commented 4 years ago

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 commented 4 years ago

Rejecting Sha3 for the following reason posted on the Sha3 ECIP https://github.com/ethereumclassic/ECIPs/issues/13#issuecomment-552680753

developerkevin commented 4 years ago

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.

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

  2. 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.

  3. ProgPoW - Hell No

soc1c commented 4 years ago

please review before the next call

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 commented 4 years ago

Starting in 30 minutes.

soc1c commented 4 years ago

Attendees

Client team checked in

ECIP-1076 "ECBP" mining change process?

ECIP-1070: ProgPOW

ECIP-1049: Keccak-256

zmitton commented 4 years ago

@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 commented 4 years ago

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

sorpaas commented 4 years ago

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 commented 4 years ago

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

soc1c commented 4 years ago

the decision was made. please review https://github.com/ethereumclassic/ECIPs/pull/194

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

sorpaas commented 4 years ago

@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 commented 4 years ago

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

sorpaas commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

continued in #333