EIP-1052 failed to go through the workflow

[fulldecent]

EIP-1052 is currently listed as draft status, however according to announcement from @Souptacular at https://blog.ethereum.org/2019/01/11/ethereum-constantinople-upgrade-announcement/ the latest EF version of clients will support this hard fork on block 7,080,000.

@Arachnid @chfast please use the EIP workflow process outlined in EIP-1.

[axic]

These are addressed in #1689 (and #1642 to be merged after the hardfork goes live).

[fulldecent]

Thank you for the reference. I request please that in future, project managers will promote to LAST CALL and then ACCEPTED status /before/ an EIP will be announced as part of a hard fork.

[5chdn]

addressed in #1689 and #1642 - will not happen again

[fulldecent]

There is a bug in 1052 and it should not be included in Constantinople in its current form.

I submitted it for the Ethereum Bug Bounty. And I didn't read the details of whether I am allowed to fully disclose details while it is being considered for bug bounty, so I won't say anything else here yet.

[5chdn]

1052 is final, it cannot be modified anymore.

[bmann]

@5chdn it can't be amended? What's the process for superseding it or amending it? A new EIP?

[fulldecent]

The EIP-1052 issue

Here is my issue with EIP-1052 (the version as of 80b8f80).

I believe this test case:

"The EXTCODEHASH of an precompiled contract is either c5d246... or 0."

is ambiguous and could lead to multiple, conflicting implementations. That of course would lead to a network split and cost billions of dollars.

The solution is to provide more explicit test cases, one that returns c5d246... and one that returns 0.

---

Disclosure timeline:

2019-01-21 -- I identified issue and disclosed to EF under the Ethereum Bounty Program since it could lead to a network split and that is a security issue.
2019-01-21 -- The author of the EIP replied privately and defended that no change is necessary
2019-01-22 -- Another number of EF replied privately and defended that the current EIP is clear as specified and that no change is necessary.
2019-01-24 -- A member of EF invited me to publish this
2019-01-26 -- I am posting this publicly.

Practically speaking, any impact this issue report could have is limited by the fact that EF controls every/nearly every implementation of the client and the upgrade path of all deployed clients.

I do recognize that the value of using the full two-week EIP process and fixing standards is more important for the actual decentralized future and setting a good example, rather than worrying about what might happen the day after this current fork.

[5chdn]

A new EIP?

Exactly.

[bmann]

A new EIP? ...

@5chdn a new EIP which has a classification of “Supersedes”? Are there existing examples of this you can point me at?

[5chdn]

EIP #98 versus #658 (Parity implements both and uses 98 on Kovan but 658 on Mainnet)

EIP #1087 versus #1283 versus #1706

[bmann]

Can we close this issue?

[5chdn]

Yes. In future, the cat herders eip monitoring subcommittee will assist here.

ethcatherders/hard-fork-checklist#4

[axic]

Closing this now as I don't think it is relevant anymore. The problems raised are valid, but likely it should be discussed on the Ethereum Magicians forum or as part of a broader discussion regarding processes (and not specific to EIP-1052).

@fulldecent please let me know if you want to keep this open.