Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Feb 28 2019 19:45
    @Arachnid banned @merkle_tree_twitter
  • Feb 17 2019 00:56
    @jpitts banned @Aquentson_twitter
  • Apr 09 2018 04:14
    @holiman banned @JennyJennywren_twitter
  • Oct 21 2017 19:12
    @Arachnid banned @Musk11
Martin Holst Swende
@holiman
StPetersburg, or Alexandria to keep the historic touch?
Marius van der Wijden
@MariusVanDerWijden
It means cat's elbow and is a tiny village in germany
I like Alexandria
Paweł Bylica
@chfast
@gumb0 the mainet will go like: Byzantium -> ConstantinopleFix. I prefer different name if the "Constantinople" must stay as defined some time ago.
For some practical reasons I also prefer:
  1. Single word name, so not StPetersburg nor ConstantinopleFix.
  2. The name that does not use the same first letter as previous / next upgrades.
Paweł Bylica
@chfast
do we still assume the upgrades happen in order: Byzantium > Constantinople > Petersburg. Or Byzantium > Petersburg is also acceptable?
Tomasz Kajetan Stańczak
@tkstanczak
I guess it should be Istanbul
:)
taking into account that Constantinople and Byzantium were the names of the same city which is Istanbul nowadays it would keep it meaningful
(obviously any name would do - I would keep Alexandria for the big Eth 2.0 Lighthouse release)
Paweł Bylica
@chfast
@tkstanczak too late. The "Istanbul" name was proposed for post-Constantinople upgrade... which is now post-Petersburg one.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Frank> Quorum have a consensus engine called Istanbul they will want upstreamed into geth so might be worth avoiding that word.
Tomasz Kajetan Stańczak
@tkstanczak
Samarqand
5chdn
@5chdn
It doesn't really matter how we call it as long as it contains Peter.
Christoph Burgdorf
@cburgdorf

@chfast I guess that is ultimately up to each client and the nets it wants to support. A client that wants to support Ropsten would support transitioning from Byzantium > Constantinople > Petersburg

For mainnet, I guess we all agree that at no point in time, there will be a transaction executed under the Constantinople rules. My understanding is that geth plans to configure Constantinople and Petersburg to activate on the same blocknumber for the mainnet. But that seems like an implementation detail of geth. At the end of the day, what matters is that no transaction on mainnet would be executed under these rules.

Paweł Bylica
@chfast
@cburgdorf yeah, but consensus tests generation depends on C++ codebase, so it would be stupid to drop Constantinople suddenly even though I'd love to.
Christoph Burgdorf
@cburgdorf
@chfast yes. I guess we need to keep it. Strictly speaking, it's part of the wider Ethereum protocol, just with the oddity of being irrelevant for mainnet :)
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Frank> @5chdn Not necessarily. It turns out there is a county of Szilagyi https://en.wikipedia.org/wiki/Szilágy_County so we could actually go for Zilah, the capital.
Tomasz Kajetan Stańczak
@tkstanczak
it is neighbours with Szilágysomlyó
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Frank> lol
Jacek Sieka
@arnetheduck
opportunity to stress that international character support..
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Frank> ok let's do it. 😃
Danno Ferrin
@shemnon
Jamie Pitts
@jpitts
Protocol updates could follow the practice of "release candidate" within the semantic numbering scheme. And these clever release names, this is over-arching for the upgrade initiative and sticks once it stabilizes on mainnet. Constantinople is what you are attempting to get mainnet to.
So what you attempted to release was ethereum-8.0.0-rc1, released to the testnets and prepared for mainnet. An issue was found, therefore rc1 was aborted. The main network remains at ethereum-7.x.x. Now you proceed with ethereum-8.0.0-rc2, first on ropsten, etc, and then attempt to release to mainnet.
Jamie Pitts
@jpitts
The "release candidate" approach allows you to keep attempting to get from 7.x.x to 8.0.0, by incrementing the x in 8.0.0-rcx. It allows you to not have to worry about the name, which is marketing and communication to the wider community. Once a stable rc-x happens on mainnet, well, IMO that is what becomes "Constantinople". LMK what you think @chfast and @cburgdorf.
Lane Rettig
@lrettig
Sounds perfectly reasonable to me
Danno Ferrin
@shemnon
I’m in favor of the “Constantinople has EIP-1283” approach and that a fork to remove EIP-1283 is a differnt fork, that should get a new name and probably a new EIP. The standard I would think should apply is that once an AllCoreDevs decision has been made to deploy a fork to a testnet that then contents and semantics of the fork are frozen and immutable, much like a transaction that has been published on a blockchain. You can change it later to fix things, but it’s a different change. #ForkPetersburg
Semantic versioning I don’t think is a good idea because software is much easier to publish, ship, and interchange. Ethereum network upgrades happen once or twice a year. Client software gets released tens to hundreds of times a year.
Michael - Blurpesec
@blurpesec
Constantinople Fork => Lausanne Fork => Istanbul Fork ?
Little late to the party..
Christoph Burgdorf
@cburgdorf

@jpitts I believe what you are proposing is more or less what I also proposed before. I would rephrase it as: What is currently live on Rinkeby, Ropsten, Kovan, Görli and xDAI is further on referred to as ConstantinopleRC1 and the next fork that is planned to go live on mainnet Feb 27th will be referred to as Constantinople.

But I'm under the impression @5chdn (and others) feels kinda strongly that we can not reuse the name Constantinople for that upcoming fork and should continue to use this name for the rules that are currently live on these other nets.

The one thing about using an entirely new name such as Petersburg is that it might cause confusion in the wider ecosystem.
Christoph Burgdorf
@cburgdorf
So, I'm personally on board to rename what is currently live to ConstantinopleRC1 or FallenConstantinople or whatever else to let us set free the name Constantinople for the 2nd attempt. However, I'm lacking the experience of e.g. @5chdn so I might be underestimating other troubles that such move may cause.
I do not feel strongly either way.
Jamie Pitts
@jpitts
Maintaining clear communication to the community is why I think that the name Constantinople should be a description of the intended upgrade to mainnet.
The community is going to get very confused if the name changes too much and IMO a name advance is only for major increments, i.e. forking changes on mainnet. But devs and operators perhaps need specific, numbered versioning in order to reason about what is added, removed, what is actually deployed.
Jamie Pitts
@jpitts
In this case of deploying Constantinople, if the content of EIPs or set of EIPs changes, then this would be reflected in the rcx. Client software targets these, with their own versioning preserved. Each testnet with a failed release would have a specific 8.0.0-rcx running, and clearly known what protocol is deployed there.
Danno Ferrin
@shemnon
My concern with recycling Constantinople and not using a distinct name is that end users will only do cursory web searches and be 'OMG! My chain the Constantinople fork and that is the one with the security issue!’ and saying we renamed the broken one won’t change the number of press articles already written. So ConstantinopleFixed or ConstantinopleV2 would help with deliniating rather than trying to back in time and double spending a code name.
Jamie Pitts
@jpitts
You do have a good point; lacking more clarity in the current situation, now and in the near future "Constantinople" can be misunderstood. Later on, if versions are employed and communicated in articles users may be better informed about this (e.g. Constantinpole 8.0.0-rc1 presents problems for some contracts, but 8.0.0-rc2 which became 8.0.0 addressed that).
Adrian Sutton
@ajsutton
The big problem with any form of renaming of already deployed fork is that it affects the contents of genesis configs which specify which block that fork starts at by name. RC numbering has a similar problem in that once you deploy RC1 to Ropsten you have to continue to support HardForkRC1 as an alias for HardFork even if, as is usual, there are no changes. It’s quite confusing to have multiple names for the exact same thing.
5chdn
@5chdn

It's really very easy.

Constantinople:

  • EIP-145
  • EIP-1014
  • EIP-1052
  • EIP-1234
  • EIP-1283

St. Petersfork:

  • disable EIP-1283

Constantinople + St. Petersfork

  • EIP-145
  • EIP-1014
  • EIP-1052
  • EIP-1234

It's fine if media reports about Constaninople, but we all need to acknowledge as engineers that it's more than Constantinople, even though, in the sum, it's less.

We don't need to rename the entire thing and go on TV Shows talking about Peter's fork or whatever. But we need some internal label to distinguish the differences.
5chdn
@5chdn
Created a hardfork meta ethereum/EIPs#1716
Jamie Pitts
@jpitts
Good notion to wrap the new set of changes in a HF Meta EIP, so the idea is to create a new one for each "attempt"? I def. think the history of an attempt or candidate on the testnets should be documented. In the scheme I have in mind, any increment of x.x.x-rcx would mean that it represents a new attempt to get mainnet to 8.0.0, and is a fork, perhaps deployed to testnets but not deployed on mainnet.
In this numbering scheme I would also position the St. Petersfork as a 7.x.x PATCH https://semver.org, if depicted at all. This is because the change would not advance the target network to 8.0.0.
Danno Ferrin
@shemnon
I don’t think semver is a good model becaue every hard fork would be a major change that is not backwards compatible. We may as well just use a single number. The closest would be that the numbers would be <hard fork>.<soft fork> and Eth doesn’t do many soft forks. If we have to touch the difficulty bomb it’s automatically a hard fork.
William Entriken
@fulldecent
Now that we have delayed Constantinople deployment, can we please have the breaking-change EIPs go through the normal EIP process, which includes a two-week last call process for each of the changes?
I am submitting another vulnerability now.