Ethereum Core Devs Meeting 55 Agenda

[lrettig]

Ethereum Core Devs Meeting 55 Agenda

• Meeting Date/Time: Friday 15 February 2019 at 14:00 UTC
• Meeting Duration 1.5 hours
• YouTube Live Stream Link

Agenda

1. Roadmap a) Constantinople: Ropsten fork / status b) CREATE2 side effects for education c) ProgPoW Audit d) Reject EIP 1355 "Ethash 1a" e) Istanbul Hardfork Roadmap x Proposal Deadline May 17th x EIP 1418 State Rent x HF Naming challenge f) Outlook: PoS finality gadget on PoW chain (Serenity)
2. Working Group Updates a) Ethereum 1.x Stanford Meetings Overview b) State Rent c) EWasm d) Pruning/Sync e) Simulation f) Appetite for future in person meetings?
3. Testing Updates (time allowing)
4. Client Updates (time allowing) a) Geth b) Parity Ethereum c) Aleth/eth d) Trinity/PyEVM e) EthereumJS f) EthereumJ/Harmony g) Pantheon h) Turbo Geth i) Nimbus j) Mana/Exthereum k) Mantis
5. Research Updates (time allowing)

[MoneroCrusher]

Here's a small what-if calculator I made for your convenience to see for yourself how ProgPoW Original vs. ProgPoW 3-phase (my proposal for a better ProgPoW deployment) would play out for you personally.

Link to view only the preset values at 15c per kW/h Link to copy to your own Google account to be able to edit your own version Link to the .ods file (LibreOffice)

Assuming a 70% infestation of ASICs of the Ethereum network a ProgPoW 3-phase deployment would initially be almost 1000% more profitable for a hobby miner paying 15c per kW/h. A ProgPoW 3 phase implementation economically disincentivizes ASICs (reiterated by Linzhi), while with a static ProgPoW implementation ASICs would be up and running after a few months again.

In this example I ignore that the hashrate of ProgPoW 3-phase (phase 1) would actually be higher, but it doesn't matter since all GPUs would rise in hashrate at the same time, thus they have the same relative speed, which wouldn't change this calculation.

If ProgPoW gets adopted we need to make sure it benefits Frank, 19, living in mom's basement, owner of a 12 GPU rig. We don't need to make sure that Tom, 43, owner of a 50,000 GPU megafarm paying 2-3c per kW/h benefits overproportionally from the change in comparison to Frank.

My goal with this is the growth of the Ethereum network and growth of cryptocurrency as a whole. The best tool to grow the network is by word of mouth to friends and relatives by hobby miners and other enthusiasts. If you cut them off you will have an isolated circle of insiders that ultimately derive value of Ethereum because all they care about is pleasing their investors who sometimes couldn't care less for cryptocurrency. This article sums it up very nicely

DON'T FORGET WHAT THIS IS ALL ABOUT:

[hackmod]

@MoneroCrusher // you've missed reference link recently written by @ifdefelse https://medium.com/@ifdefelse/progpow-progress-da5bb31a651b

from https://medium.com/@ifdefelse/progpow-progress-da5bb31a651b

Reducing Compute

After testing on a wider variety of GPUs we’ve discovered the current parameters unintentionally causes some AMD GPUs to be compute limited instead of memory limited. Reducing the random cache and math counts by 10% increases the hashrate on those AMD GPUs. This has no effect on the hashrate of other AMD GPUs or any the Nvidia GPUs we tested. (snip...)

[MoneroCrusher]

I'm aware of this, however this is not about AMD or Nvidia, this is about optimizing power consumption generally, while keeping ASICs away even better and increasing profits for hobby miners drastically in comparison to the original implementation plan.

(on the side: Lmao at that explanation. As if they "unintentionally" forgot to tune for the most used commodity hardware used for Ethereum mining. They decided to change parameters only after taking a lot of heat from the community, before that they showed 1000 "technical" explanations of how everything is perfectly tuned. I very much love how they say "unintentionally causes some AMD GPUs to be compute limited", why don't they instead say "unintentionally causes AMD Polaris, the most widely used chip used for mining Ethereum to be compute limited" Let's stop talking about this right here though, don't want to make this the topic of discussion, we can use reddit for that).

[ASICseer]

I agree with Ethereum core devs that they need to completely step back from this debate and not give it a platform on their dev channels (youtube calls, github issues, reddit posts).

This issue basically decides who gets to mint new coins, and the ETH dev team should not be acting like the US Federal Reserve. They should not be inviting third party developers with unproven codebases into their midst and letting them whisper into their ears.

We can all admit that a lot of money is at stake, and if ETH devs provide a platform for this debate on their channels, they expose themselves to the potential of backhanded dealings, bribery, coercion. The only way for users to trust developers in the future is for them to remain completely impartial on this issue.

https://twitter.com/5chdn/status/1090752365190438912

As far as I understand it, some developers publish user-facing statements regarding what they consider to be a consensus among them. I agree with their consensus that the developers should remain completely impartial. While it may be true that some developers might have slightly different opinions, it comes off as extremely weak-willed if ETH appears to have developers bickering on Twitter.

Furthermore, any potential audit of progPOW would not be conclusive, it does not address the problem of misaligned economic incentives. Third party auditing firms should have absolutely no say in decisions related to coin governance. Finally, third parties would be exposed to the same bribery and coercion as ETH devs.

If ifdefelse likes progPOW, they should launch their own coin instead of trying to co-opt Ethereum.

[MoneroCrusher]

I partially agree, they should not be the deciding factor, but they need to offer the platform so users have the possibility of expressing themselves and ultimately decide with their hashrate.

I heard about a voting that should apparently take place on Ethereum via block messages. This is a very bad idea if we assume that ASICs are far better organized (because central) and if ASICs are more than 50% of the network, it's an instant loss anyways.

Instead they should IMO definitely ditch Ethash in its current implementation because it's proven to be ASIC infested (https://www.asicminervalue.com/miners/innosilicon/a10-ethmaster-485mh), there's no point in doing a vote on the current/legacy chain when ASICs are able to vote, when the vote is about GPU mining. You don't want Kazakhstan being able to cast their political vote in France, right?

So what I would ultimately like to see is the developers setting a block height on which the PoW fork has to take place. All proposals that are reviewed and have successfully been run on testnet then all get simulataneously activated on fork day and each GPU miner can decide which chain to go for. Eventually after some days we will have a clear picture and the devs can announce to support the strongest chain and the GPUs from the loser chain(s) will be economically incentivized to join the longest chain and the loser chains slowly die off.

That is the most impartial way this can be done and the fairest one to all participants.

Possibilities I currently see:

1. ProgPoW (IfDefElse) - temporarily kicks off ASICs & +60% power
2. 3-Phase ProgPoW (MoneroCrusher) - economically disincentivizes ASIC until PoS & +10%+30%+60% power (that is if IfDefElse don't accept my proposal)
3. Ethash + small tweak (with the rationale that PoS is coming soon anyways and new ASICs wont get created to mine for e.g. 1 year) - temporarily kicks off ASICs

[lrettig]

This is not the place to debate progpow, or any other topic on the agenda. This is a meta-topic for planning the next all core devs call. Hudson, Afri and I cannot scroll through hundreds of comments looking for topics relevant to the meeting agenda. Please take this debate to https://ethereum-magicians.org, Reddit, or another forum, but not here.

I've marked these posts as off-topic and will lock this post to open commenting if it continues.

[sneg55]

This is not the place to debate

Then what's the point of making agenda and devs calls available for the general public?

[lrettig]

Core devs calls are open for public observation but they are not a forum for public debate. Other forums such as the ones I mentioned are the right place for that. We do our best to listen to and engage with the community, and to factor in concerns and community sentiment on the calls.

[ghost]

We need a dedicated forum for ProgPoW discussion, should I start building them?

[lrettig]

Check out https://gitter.im/ifdefelse/community and https://gitter.im/ethereum-mining

[ASICseer]

This is not the place to debate progpow, or any other topic on the agenda. This is a meta-topic for planning the next all core devs call.

Very sorry for going off-topic. I am curious regarding the standard of competence and influence as it pertains to third-party audits of code (whatever that code may be), that the ETH dev team deems acceptable. Will the dev team plan for an audit of the original audit to determine whether or not the third party auditors were 1) competent in their evaluation and 2) not influenced by economic actors and other possible special interests? If so, how long would that audit take, and how would you determine whether or not it was conclusive?

[lrettig]

@naikmyeong @gpushack I opened https://ethereum-magicians.org/t/on-the-progpow-audit/2594. Please post your questions there. This is not the place. The progpow audit is already on the agenda for this call.

[chfast]

Reject EIP-1355: https://eips.ethereum.org/EIPS/eip-1355.

[bmann]

@lrettig @Souptacular going to try again with less mining comments than my last post :)

Discussion if there is interest for a mid-April in person meeting https://ethereum-magicians.org/t/eth1x-istanbul-prep-meeting/2396/2?u=boris

And more generally, what a cadence of in-person meetings looks like for other hardfork roadmap key dates. Do CoreDevs need to meet in person regularly? What topics are useful to do in person? Can I and others help with some of the planning / logistics?

[fulldecent]

It will be helpful if the agenda above could link to specific working groups. (Is there an ongoing hangout where each is discussed?)

Regarding item State Rent, the past three meeting minutes show no discussion on this. Requesting to add draft EIP 1418 to agenda if this is in scope. I believe the main speaker on this topic is @AlexeyAkhunov. Thank you.

[carver]

Would like to mention the CREATE2 side effects, at least to encourage everyone listening to help educate their own networks about the change.

[emansipater]

Yes, I think doing some "general education" around CREATE2 would be very helpful here, especially looking forward to some of the things that are going to be happening going forward towards 2.0 with nonces, contracts, addresses, and some of the statefulness assumptions in the CREATE patterns currently being used. I would love to join in and add some color on this if it would be useful. I think especially it's important to talk about where we want to end up on addresses, self-destructs, etc.

[Souptacular]

Closed for https://github.com/ethereum/pm/issues/82