-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Data Gathering for Post-Mortem of Constantinople Hard Fork Delay #1
Comments
Q: Why was the possibility of reentrancy discovered so late? A: Via gitter, by @holgerd77:
These are, obviously, "candidate Q" and "candidate A". Tip: to get markdown if you don't have |
Some bullet points I've been collecting: Things that could / should be considered when writing / choosing / merging EIPs:
Potentially things clients should do:
Misc
|
I made this during the emergency call, "The Decision Process For The Constantipole Ethereum Hard Fork / Network Upgrade Postponement": https://docs.google.com/document/d/1gr0hHAxobzpLYDXZnZFk6qPuv8_to3XLNQ9TvXMCWxw/edit?usp=sharing I added ideas and suggest we all deconstruct the process and suggest ideas for future decision making ✍️ |
|
|
Adding my reply from gitter:
|
Regarding automated testing: this time, it was not discovered by fuzzing. |
Is this the kind of thing that fuzzing is looking for? The problem is that an invariant is being broken which nobody had previously written down. |
Had some exchange on this with Ralph who is the organizer of our local Vienna Ethereum meetup and helped to discover this: he told me that he actually knew about this for months (sigh) and just thought that ChainSecurity would have already reported this. Instead of blaming anyone here (Ralph: surely not, ChainSecurity: there might be some questions) I think we can go one level higher and state that there are definitely some communication issues here, since the information was there in the community, it was just not possible to harness. Ideas to address this could be some bug bounty program, or at least some "Community call to submit every suspicion of a bug/fork inconsistency/weird behavior" blog post somewhere in a fork preparation process. |
I wouldn't say "knew", more like "suspected". I thought surely somebody else already thought of this at some point (since it seemed obvious) and that surely it wouldn't work for some reason. Anyway I wanted to test this on Ropsten first (as I already submitted a bounty in the past and back then it turned out to be an issue with testrpc instead), but that was a side project that just ended up getting delayed and delayed again for various reasons. |
This cannot be emphasized enough. While I understand the desire to fully verify a problem/bug before reporting, doing something is better than nothing. That something could be bringing it to the attention of developers, other security researchers, or a variety of other people in this space. Another option would be to post on the EIP itself. What types of things could be done to help ensure people like Ralph put the information out there, even if its not a confirmed bug? Brainstorming here....
|
Both the Ethereum Foundation and Parity Technologies have a bug bounty program. I'm rather surprised this is not known. |
I'm guessing there's some diffusion of responsibility at play here. |
Another suggestion: a hardfork drinking game bingo card should be made for all upcoming forks. Hudson has an example card template that can be used. |
This thread is designed to capture information, thoughts, ideas for topics to discuss in a post-mortem of the decision to delay the Constantinople hard fork, which are unable to be addressed in this moment.
Thank you for your contributions and patience.
The text was updated successfully, but these errors were encountered: