Since Yolo v3 is still in very active movement (just restarted three days ago triggered by @holiman) I think it is safe to give this a minimal extension estimate (so: not a timeline but just an estimate how this is minimally delayed based on the facts right now):

• 1 week until clients get on board on the restarted testnet Wednesday Feb/24
• 2 weeks running Yolo v3 and see if things are stable Wednesday Mar/10
• Buffer of 2 weeks assuming there is 1 issue found between clients Wednesday Mar/24
• Settling the dust, one week client preparation time to include a new HF block for Ropsten Wednesday Mar/31

=> Minium Ropsten start date: Wednesday Mar/31

Just as some calculation for orientation (I find this personally still a bit (too) ambitious, but might be doable if we focus).

Ok, like this?

Yes, when seeing this and going a step back I think this might even be a good balance on timing needs so that we are not getting too close to #245 and a somewhat realistic timelime for implementation if everyone focuses.

Added to the agenda, @q9f !

@holgerd77 re:

2 weeks running Yolo v3 and see if things are stable Wednesday Mar/10

Why do we want that before forking the testnets? IIRC, we've used the yolo networks in the past to just test that clients can sync to each other, and we've fuzzed them a bit with transactions. I don't think this needs to take 2 weeks.

Re:

Buffer of 2 weeks assuming there is 1 issue found between clients Wednesday Mar/24
Settling the dust, one week client preparation time to include a new HF block for Ropsten Wednesday Mar/31

I think maybe we can do something like set the fork block once all clients sync to each other, for 3 weeks in the future. WDYT? IMO 1 week to put out a release and distribute it after a bug has been found is short, so I think the best we can do is plan for the "happy case" where clients are all in sync, and then have clients put out a release with a block 2-3 weeks in the future.

plan for the "happy case" where clients are all in sync

I am always a fan of planning for the "non-happy case". 😄 In the JavaScript team we perceive EIP-2718 and EIP-2930 as rather complex from an implementation PoV, currently doing the implementation (ethereumjs/ethereumjs-monorepo#1048) and I would think that having 1-2 more issues with these EIPs (not for us isolated but between teams) - maybe also along some edge cases in the specs - is rather likely than not, also judging from the current discussions on ACD.

A buffer has also the advantage that it reduces the cost of additional delay planning - especially for such short periods like 2-3 weeks or so. We already had this often in the past and there is a substantial coordination effort here in case (additional calls, new client releases, (public) communication), also to note a not-so-optimal outer perception if there are too many delays.

But at the end I am also fine with the happy-case planning and the 3-weeks-in-the-future date setting for the first testnet fork. 🙂

FWIW, my preferred approach would be something like Scenario C, without Kovan happening in parallel, given OE will deal with it post-Berlin (link). So it would look something like:

This gets us on mainnet 1 week earlier, and will give us a ~2 month window between Berlin and London hitting mainnet.

Based on the discussion in #245, another proposal may be to have the first testnet fork sooner. All clients are already syncing on YOLOv3, so we could do something like:

This gives a longer delay between Berlin and London (say London happened mid-July, that's a full 3 months), and it also gives 3 weeks from now for the first testnet to fork.

Based on the discussion in #245, another proposal may be to have the first testnet fork sooner. All clients are already syncing on YOLOv3, so we could do something like:
Scenario D HF Date
Ropsten 10 Mar 2021
Goerli 17 Mar 2021
Rinkeby 24 Mar 2021
Mainnet 14 Apr 2021

This gives a longer delay between Berlin and London (say London happened mid-July, that's a full 3 months), and it also gives 3 weeks from now for the first testnet to fork.

Potential block numbers:

• Ropsten 9_812_189 (10 Mar 2021)
• Goerli 4_460_644 (17 Mar 2021)
• Rinkeby 8_290_928 (24 Mar 2021)
• Ethereum 12_244_000 (14 Apr 2021)

 9694006 + 27221 * 60 / 13.8 =  9812358.17391304347826086957
 4311045 + 37300 * 60 / 15.0 =  4460245
 8101037 + 47378 * 60 / 15.0 =  8290549
11887875 + 77613 * 60 / 13.1 = 12243354.38931297709923664122

Diff bomb: https://eips.ethereum.org/EIPS/eip-3238

TBH I am not a fan of closing this already, can't we keep this open as a reference PR until all dates have been executed upon (or what would be an alternative go-to place to look up these numbers)?

There will also likely be (some) continued need for discussions around block numbers, additional comments on timeframe concretizations, and the like. All this would be suited to happen here.

updated PRs

if we consider this "final" I don't mind closing this, but I agree we should keep the London conversation open.

Re-opened for now. Let's consider the blocks final, and close the issue once Berlin is live 👍

Ropsten forks when this comment is 4.98 days old.

Ropsten forks when this comment is 4.98 days old.

This is in less than two days now. Since go-ethereum hasn't even got a release out with the fork activations and a removed EIP-2315 EIP yet (which is totally understandable since removal is just some days old), is it safe to assume that at least the Ropsten fork will be postponed? 🤔 (has there been some discussion around that that I missed, couldn't find anything?)

What's with the other fork numbers, should everything be postponed by a week here?

ACD call on Friday say they want to go ahead with the fork as scheduled originally, so that's what we've went with.

Also, Geth v1.10.1 was released just after you made your comment :D https://github.com/ethereum/go-ethereum/releases/tag/v1.10.1

@karalabe thanks, that's nice that you confirmed here. 🙂

Yep, confirming we agreed to keep the fork blocks as in this comment on ACD. We'll also have a blog post out today (hopefully!) with the details of the upgrade.

Blog post: https://blog.ethereum.org/2021/03/08/ethereum-berlin-upgrade-announcement/