Hi! I'm a bot, and I wanted to automerge your PR, but couldn't because of the following issue(s):

• Trying to change EIP 1013 state from Draft to Final
• EIP 1014 is in state Accepted, not Draft or Last Call
• EIP 1052 is in state Accepted, not Draft or Last Call
• EIP 1234 is in state Accepted, not Draft or Last Call
• EIP 1283 is in state Accepted, not Draft or Last Call
• EIP 145 is in state Accepted, not Draft or Last Call
• EIP 1013 requires approval from one of (@nicksavers)

Can we get this merged soon? ref #1716

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.

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

Whatever the outcome is, Constantinople is final as it is active on Ropsten, Kovan, Rinkeby, Sokol and xDAI already. If we need to disable it, we will need a new upgrade. This does not affect EIP-1052 or 1013.

@fulldecent we answered, that submission is not an issue, it's a false positive. Feel free to share.

@holiman Thank you for the quick response!

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 why did you close this? I think this one should be merged.