Hi @5chdn, the youtube link goes to the 52 livestream :) Is that correct?

@kevinsimper I have updated the link.

Food for thought about the postponing:

Independent of what the actual fix to SSTORE will be, we'll have an issue that the original rule set is already active on Ropsten and Rinkeby under the name Constantinople (not sure about Kovan and the other PoA networks). If we change the meaning of the Constantinople fork to some new feature set, it will be a mess wrt the testnets. Clients (at least Geth for sure) would need to introduce further splitting logic to differentiate between testnet-constantinople and mainnet-constantinople (which still messes up privatenet-constatinople, needing some user configurability).

My alternative suggestion - that would keep the fork semantics clean - is to keep the Constantinople feature set as it is currently and introduce whatever fix we dream up in an Istanbul fork. Ropsten and Rinkeby can fork a second time (they must either way, otherwise the EVM on the testnet will behave differently than on mainnet), and mainnet can do a double fork Constantinople + Istanbul at the same block.

This would allow mainnet and the testnets to keep the same semantic meaning of the named forks. It's also the classical fork procedure we've always done, so every client will support it without any extra code modifications or behavioral splitting needed. Furthermore it would also allow us to keep all the existing Constantinople tests and just extend the suite with a new fork, instead of remaking everything.

@karalabe Referring your thought there will be no Constantinople upgrade on mainnet until Istanbul is being finalized right?

@naikmyeong Not sure we're talking about the same Istanbul. My proposition is analogous to renaming Constantinople to Constantinople 1 and have the fix in Constantinople 2, where testnets only need to apply Constantinople 2 now, but mainnet would apply both 1 and 2 at the same block.

However, to avoid the naming confusion of Constantinople 1 and Constantinople 2 after clients already defined what Constantinople means, my recommendation is to keep Constantinople 1 as Constantinople and use a meaningful name for Constantinople 2, which can be either Istanbul or anything else really.

My suggestion has nothing to do with any previously discussed hard forks that were named Istanbul.

FYI ethereum/EIPs#1701

I understand, I agree for having Constantinople 2 as a bug fix of Constantinople 1, and I suggest having a same time period that we've already had with Constantinople 1.

Independent of what the actual fix to SSTORE will be, we'll have an issue that the original rule set is already active on Ropsten and Rinkeby under the name Constantinople (not sure about Kovan and the other PoA networks). If we change the meaning of the Constantinople fork to some new feature set, it will be a mess wrt the testnets. Clients (at least Geth for sure) would need to introduce further splitting logic to differentiate between testnet-constantinople and mainnet-constantinople (which still messes up privatenet-constatinople, needing some user configurability).

For Parity this is not an issue. We can turn on and off EIPs separately. On Kovan we only use a subset of Constantinople anyways. Regarding Ropsten, we are talking about a potential deprecation anyways. Time for a new testnet?

However, we need to find a way to patch existing networks anyways in case other mainnets activates Constantinople already.

For Parity this is not an issue. We can turn on and off EIPs separately. On Kovan we only use a subset of Constantinople anyways. Regarding Ropsten, we are talking about a potential deprecation anyways. Time for a new testnet?

Didn't you said that Goerli will replace Ropsten? 😂

For Parity this is not an issue. We can turn on and off EIPs separately

We need to consider UX here as well. I wouldn't want to require users to run parity with a complex commandline flag, or a config file, just to sync mainnet or one of the main testnets. I'm with @karalabe's proposal here, it sounds like the most straightforward.

Quick recap on the difficulty bomb: as discussed in meeting 49:

• Block times will begin to increase in Jan
• Expected to reach 30s block times in May
• Could be as early as early April if hashpower declines ~20-25%
• Will hit faster than last year

It looks like block times have just begun to tick up. Since the math was done it appears that hash power has come down by about 20%, so my best forecast at the moment is that we'd hit 30s block times in late April.

Based on commentary around reddit / twitter / forums, the most pressing questions. These are basically expansions on the bullet points listed in # 5 of OP.

1. What will be done for EIP 1283?

   • Recommended reading/commenting before the call: https://ethereum-magicians.org/t/remediations-for-eip-1283-reentrancy-bug/2434/7

2. Timeline for new fork?

   • I personally strongly recommend picking a date on this call, based on what is determined in point 1
   • Most armchair estimates range between 2-6 weeks
   • If devs could be fairly explicit in the things that affect this timeline, would help on comms side, especially if timeline is longer rather than shorter (e.g. tests need to be re-written, testnets need to be dealt with, etc.)

3. How did this happen? Why wasn't it detected sooner?

   • Who is owning creation of a more thorough retrospective? Timeline? Where can people contribute?
   • Can be very brief, or can be more in depth on call and discuss the good/bad/ugly of what happened.
   • Request for comments on any things that should be included in retrospective (general or specific)
   • Data Gathering for Post-Mortem of Constantinople Hard Fork Delay ethcatherders/hard-fork-checklist#1

4. Testnet plan

   • There has been a surprising amount of commentary on this

There should be a discussion surrounding the issue for how upgrading will be dealt with in the future. We would not want to establish a base line that allows future manipulation of the upgrade process by nefarious actors. One offending EIP, should not delay without "good cause" the upgrade timing of other non-offending EIP's that were scheduled during the same upgrade instance of the platform. Otherwise, one can manipulate how and when other included EIP's are deployed or not deployed. We should not set a bad precedent, otherwise we should expect bad actors to manipulate the upgrade process in the future.

@rfikki do you think the reentry article was intentionally withheld until the day before the fork? In a way, the article was a test of how responsive the primary ETH developers are and it shows that all you need is one well-timed article to change the entire ETH development timeline.

Nope, @cartercarlson I do not think the article was intentionally withheld. I am making a point that in the future anyone that wants to manipulate the process knows based on this instance that they may be able to do so from how this scenario was handled.

FYI: Results of our survey regarding ProgPoW & a general PoW change. So far out of ~2400 votes (mostly miners), 82% are in favor of moving to a different PoW algorithm (45% are for ProgPoW, 34% are for another ASIC resistant algorithm, 3% are for another ASIC friendly algorithm) and only 18% are in favor of sticking with ethash.

https://twitter.com/etherchain_org/status/1084349056883802112

Aleth update:

1. Aleth 1.5.0 released for Constantinople, then 1.5.1 released for ConstantiNOPEle.
2. The Aleth 1.5 contains a separated bootnode: aleth-bootnode. More improvements in p2p discovery area are coming in next releases.

Closing for #73