If a contract is worth millions, invest in some heavy duty specification testing and verification. I’m not an expert or a skilled practitioner, but what I keep reading about frama-c and ada spark really suggest that it is possible to write better things. At least some of the stupid bugs would be more obvious if the outer proved specification (not even a complete specification) of the code had some basic assurances.
Let’s give that a try instead of greed, laziness and ignorance. It might not work, but at least you gave it a try.
My stance is the same as it’s been with Bitcoin issues, if the Core devs of the platform (go-ethereum included) are able to reach rough consensus around the issue, then I support it, otherwise I do not.
Nobody is going to be “bamboozled by Parity”. We all work in the open.
My personal stance on the issue is I’m split:
On one hand rescuing the funds doesn’t seem to hurt anyone. On the other hand, hard-forking every time devs screw up a smart contract sets an interventionist precedent that could lead to Bad Things™ down the road.
So, giving Parity Tech a figurative “get out of jail free” card on this, by hard forking, damages the long-term prospects of the whole to Parity’s benefit. It was their mistake, so IMO they should own up to it and at least cover some of the damages.
Take this situation to its logical extreme: if each time an Ethereum developer makes a smart contract mistake the system hard forks, well, it’s absolutely no different than a centrally managed financial system.
Do the people writing the software never take responsibility for their actions?
Is it always “no HF” when someone outside of the core dev group makes a mistake, and “HF” when people inside the core dev group make a mistake?
Selective enforcement like this leads to corruption.
I don’t generally subscribe to slippery slope arguments. I do think that the prevalence of requests to do head forks suggests that the rhetoric around smart contacts is off the mark. It’s probably time for ethereum to confer up with some policy guidelines around smart contract error resolution as a matter of policy so the debate can be more focused.
I’m disappointed you felt the need to change the title. The correct title, “On Classes of Stuck Ether and Potential Solutions”, is both more accurate and more interesting. I almost didn’t read this. Don’t editorialize.
My reading of this quote from the article is that a hardfork is among the suggestions Parity has put forward. Do you disagree?
A third solution, which was suggested by Parity, is a change to the Protocol which would allow the revival of suicided contracts and fine-grained deployment of contracts for all users going forward. It would restore the Parity multi-sig and other issues where contract addresses hold funds but have not had code deployed to them. It would also safeguard future incidents of a similar nature.
If a contract is worth millions, invest in some heavy duty specification testing and verification. I’m not an expert or a skilled practitioner, but what I keep reading about frama-c and ada spark really suggest that it is possible to write better things. At least some of the stupid bugs would be more obvious if the outer proved specification (not even a complete specification) of the code had some basic assurances.
Let’s give that a try instead of greed, laziness and ignorance. It might not work, but at least you gave it a try.
My stance is the same as it’s been with Bitcoin issues, if the Core devs of the platform (go-ethereum included) are able to reach rough consensus around the issue, then I support it, otherwise I do not.
EDIT: See also this tweet from Bob Summerwill:
My personal stance on the issue is I’m split:
On one hand rescuing the funds doesn’t seem to hurt anyone. On the other hand, hard-forking every time devs screw up a smart contract sets an interventionist precedent that could lead to Bad Things™ down the road.
So, giving Parity Tech a figurative “get out of jail free” card on this, by hard forking, damages the long-term prospects of the whole to Parity’s benefit. It was their mistake, so IMO they should own up to it and at least cover some of the damages.
Take this situation to its logical extreme: if each time an Ethereum developer makes a smart contract mistake the system hard forks, well, it’s absolutely no different than a centrally managed financial system.
Do the people writing the software never take responsibility for their actions?
Is it always “no HF” when someone outside of the core dev group makes a mistake, and “HF” when people inside the core dev group make a mistake?
Selective enforcement like this leads to corruption.
I don’t generally subscribe to slippery slope arguments. I do think that the prevalence of requests to do head forks suggests that the rhetoric around smart contacts is off the mark. It’s probably time for ethereum to confer up with some policy guidelines around smart contract error resolution as a matter of policy so the debate can be more focused.
I’m disappointed you felt the need to change the title. The correct title, “On Classes of Stuck Ether and Potential Solutions”, is both more accurate and more interesting. I almost didn’t read this. Don’t editorialize.
My reading of this quote from the article is that a hardfork is among the suggestions Parity has put forward. Do you disagree?