lrettig commented 5 years ago

Ethereum Core Devs Meeting 50 Agenda

Meeting Date/Time: Friday 23 November 2018 at 14:00 UTC

Meeting Duration 1.5 hours

Agenda

Document being mentioned on Coindesk.
Testing
Client Updates
Research Updates
Constantinople/Ropsten HF, hardfork timing
ProgPoW Update

5chdn commented 5 years ago

Constantinople

Just putting down an updated block number for discussion:
- 7090939 (January 16, 2019, 12pm UTC @ 14 sec block time)
- 7068475 (January 16, 2019, 12pm UTC @ 15 sec block time)
According to the Constantinople Tracker, all clients are ready now :tada:

Stureby PoW-Testnet

Scope: Redo the Constantinople hard-fork transition
Genesis/Chainspec: https://gist.github.com/5chdn/baf0eb40cbaff5a90befc52815d6950b
Dashboard http://boot.stureby.ethdevops.io/
TODO: pool(s), fork monitor

Görli PoA-Testnet

Now supported by four clients (Geth, Parity*, Pantheon, Nethermind) https://stats.goerli.net/
We could discuss a potential deprecation and replacement of Ropsten after Constantinople next year

lrettig commented 5 years ago

Just putting down an updated block number for discussion: ~ 7078690 (January 16, 2019, 12pm UTC)

Since this has come up a few times recently, here's the conversation we had in AllCoreDevs a few weeks ago about forking on timestamp instead of block number. My understanding of the reasons against doing so:

Block number is simpler and harder for miners to game. "eth hashrate base is big enough you can't accelerate the fork by anything statistically significant."
We could have a situation where an uncle block has a newer timestamp and therefore different fork rules than the canonical head
"All current tools for configuration uses block numbers (test generators, hive configuration, evmlab randomtest generator). All tests would need regeneration, and fork configuration params and logic in clients would need rewriting" (@holiman)

What have I missed?

Is there any value in continuing this debate or are we satisfied that block number is the only option?

kylerchin commented 5 years ago

The biggest thing I'm watching is the fork date and block numbers. If we can get that established, and maybe a bit on sharding progress, then my needs are met. See everyone on Friday morning! 😋

On Wed, Nov 14, 2018, 5:24 AM Lane Rettig notifications@github.com wrote:

Just putting down an updated block number for discussion: ~ 7078690 (January 16, 2019, 12pm UTC)

Since this has come up a few times recently, here's the conversation we had in AllCoreDevs https://gitter.im/ethereum/AllCoreDevs?at=5bca0f35c08b8b30673d9864 a few weeks ago about forking on timestamp instead of block number. My understanding of the reasons against doing so:

Block number is simpler and harder for miners to game. "eth hashrate base is big enough you can't accelerate the fork by anything statistically significant."

We could have a situation where an uncle block has a newer timestamp and therefore different fork rules than the canonical head

"All current tools for configuration uses block numbers (test generators, hive configuration, evmlab randomtest generator). All tests would need regeneration, and fork configuration params and logic in clients would need rewriting" (@holiman https://github.com/holiman)

What have I missed?

Is there any value in continuing this debate or are we satisfied that block number is the only option?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ethereum/pm/issues/62#issuecomment-438660138, or mute the thread https://github.com/notifications/unsubscribe-auth/AHMJ5huvdLusZ5TeBk9kxsj3mbAeTVVrks5uvBl8gaJpZM4YXWaY .

-- From Kyler Chin

salanki commented 5 years ago

ProgPoW update please

gcolvin commented 5 years ago

https://docs.google.com/document/d/1IB3oKuH5mryyhmVHE9r3aR6bK2pJCoJgAtiCYTEieh4/edit?usp=sharing

holiman commented 5 years ago

I won't make the call today. Some updates:

Two evm fuzzers are (still) running. No new issues found in the last couple of weeks.
One testcase found by fuzzing has now been added to the tests-repo. It affected geth and ethereumJ (at least), and concerned EXTCODEHASH in a fairly complex edgcase scenario.
Hive is currently down for maintenance, I have some hopes that we'll get it working again during the day. Hive has been moved into the ethereum org (https://github.com/ethereum/hive/), and a new geth-team member @FrankSzendzielarz have been working on improving it further, with a test-suite for p2p networking as well as support for more advanced multi-cllient test suites.

5chdn commented 5 years ago

https://docs.google.com/document/d/1IB3oKuH5mryyhmVHE9r3aR6bK2pJCoJgAtiCYTEieh4/edit?usp=sharing

where was this and how to get into these meetings?

June 1, 2019: target for hardfork

what is this about?

lrettig commented 5 years ago

Closing in favor of #64

ethereum / pm