Of course, this is completely normal. There will be 4 different groups:
The group that values immutability above all, and wants neither proposal to succeed.
A group that wants a general solution, but not a cherry picked solution for the Parity hack and hence would support EIP-867 but would oppose EIP-999
A group that doesn’t want a general solution, but would accept this one-time only decision. Hence this group would agree to EIP-999, but not to EIP-867.
A group that thinks either solution is a good solution and would support both EIPs.
Personally, I firmly belong to group 1. Both EIPs require an offchain decision and hence is vulnerable to bribery and extortion. Parity has a huge financial incentive to make these EIPs pass and hence have a huge financial incentive to bribe people, the media, etc. Parity might be a good actor, and not employ these tactics, however, this sets a hugely important precedent. What is to stop another actor that manages to lose a good chunk of money not to employ these kind of dirty tactics?
Also, many many funds have been lost in the past. Why should we even discuss this particular case, but not all the others? If either EIP is allowed to pass, who is going to decide which other parties will have their funds restored? This whole idea is incredibly dangerous and will set a very bad slippery slope that we should avoid at all costs.
In my opinion, the Ethereum blockchain loses much of its value if it loses the immutability property and hence I strongly oppose this EIP. A lessened form of decentralization and immutability should only be allowed to be used on sidechains. Immutability is THE most important property of the base layer and should be protected at all costs.
A blockchain based system that is vulnerable to bribery and extortion is no more valuable than legacy systems and will soon meet the same corruption that plagues legacy financial systems and politics. No thank you.
Lastly, while I do feel incredibly sorry for the people who lost money in this, this ultimately was employing extremely sloppy practices on Parity’s part. No formal third party audit after the code was changed that is handling hundreds of millions of dollars is just a sad state of affairs. A bailout here would simply give out the message it is okay to not follow best practices, because a bailout is around the corner should mistakes be made.
It seems like the All Core Devs meetings is where the final decisions on governance are made.
I think EIP-867 is the worst idea, as it makes core devs responsible for evaluating every ERP. How many ERPs do its proponents think will be drafted? I can easily picture a situation where every All Core Devs meeting involves going through 100s-1000s of ERPs, the vast majority without merit. How could the process not be abused? Bitcoin maximalist trolls could fill out tons of ERPs for very little effort.
I’m less hostile to EIP-999, but I do think that the community needs some objective criteria on what sort of smart contract screw-ups should be fixed through ad hoc hard forks. Until we can come up with that criteria and have the majority of the community agree with it, I’m against EIP-999
Unfortunately, even measuring what the majority of the community agrees with is contentious.
Trolls can already spam the EIP GitHub repo, the ERP system won’t change that. The first step is getting to draft which means getting past the editors which make sure that the proposal is at least sound/grammatically correct/technically complete, so the only things that will make it to the core devs meeting are ERPs like similar to EIP-999 where someone has a complete solution drafted up and it is well described and implementable.
This is incorrect. The All Core Devs meeting is where the various client dev teams discuss what each client team is going to implement. Ultimately the individual clients can choose what to implement but they generally prefer to all implement the same things to avoid a fork. Ultimately the final governance decision is what economic participants decide to run. Even if all of the clients implement a thing, if no one upgrades their client to accept the changes then it doesn’t matter.
I think this EIP would set dangerous precedents if accepted. This EIP outlines the recovery of a contract that was used in an unintended way where the contract contained no underlying flaw, rather it was simply misused.
Personally, I have issues with this EIP. It outlines a specific contract recovery rather than generic recovery (EIP-867). This would set precedent to create another EIP when some subjectively non-trival amount of ETH is lost by misuse of a valid contract. If I set the wrong owner on my multisig contract and lost all of my ETH, am I entitled to my funds to be recovered? The amount lost is not significant to the network and poses no risk to others, but it was my entire stash.
The decision to leave the network that is called Ethereum is a very final form of “governance”, but it’s not useful to bring it up in the context of deciding on the future of Ethereum.
The definition of what the network called Ethereum is, is decided by All Core Dev meetings. This is why we don’t call Ethereum Classic the “real” Ethereum.
I’m fine with this centralized governance, but I think the value of Ethereum will be greater if the community can agree ahead of time that certain things about the protocol should not be altered.
I think the process needs to look much closer to something like this, as that is basically a final signal that entire network sees nothing wrong with the proposal. Getting a measurement of support/no-support from the entire community would be required to vote effectively on outcomes like this proposal.
I avoid this debate, because I don’t really have any novel points to make, but I guess it’s at the stage where decisions are made by a vague sense of how loud the shouting is.
So here are my grumbling reasons for opposition:
Moral hazard. We’re not paying attention to the less influential voices who have lost a much less money, so we’re implicitly endorsing a “too big to fail” incentive model.
Future distraction. Ethereum’s competitive advantage is in a large, friendly community of contributors, working hard on scalability and usability improvements.
Making this change will ensure that we continue to revisit requests like this on a regular basis. That will continue to distract us from efforts to improve the technology for everyone. Becoming a project which constantly debates fund restoration EIPs will make Ethereum a “not much fun” open source project to contribute to, thus deterring new contributors.
EIP is an open process, everyone can file a proposal, everyone is entitled. If you are not certain about the feasibility of your request or unsure about technical details, it’s worth to create an issue first to outline the idea before actually submitting a proposal. I am happy to advise other recovery proposals, as I have done before.
These are really solid arguments to make, especially about the community being friendly and doing really awesome work, and how too much noise from recoveries would affect that.
My question is how do you stop requests like this? I think there an equally likely chance these kinds of requests continue to happen because the people who lost access to their funds are pretty well incentivized to continue trying any tactic that gets them what they want to accomplish. So we will keep seeing proposals like this occur from this hack and others like it where large quantities of valuable assets are lost.
What happens the next time an “economic threat to the entire ecosystem” occurs? What if Casper or Sharding contracts have a bug? What is the process for handling that? I think there’s balance to be struck where only the most important bugs and exploits are incentivized to go through a very complex and long-term process to ensure near-universal consensus on how the recovery should be handled.
That only happens if we are willing to discuss this as a community instead of pretending it will go away with time.
This EIP adds nothing of value to the chain. All it does is redistribute wealth from the current owners and give a little bit back to Parity. You can’t perform such an action without either tyranny of the majority or tyranny of the minority benevolent as the action may be.
Current consensus protocols are clear; put it to a vote to the miners. That’s the whole point of Proof-of-Work.
It seems incredibly, incredibly foolish to me to change the fundamental operating assumptions of a block change for an issue that negatively affects less than 1% of the total supply. I can’t believe it’s even a discussion.
I am philosophically in favor of being able to perform actions such as EIP-999, but only after a very thorough analysis of potential outcomes and engaging in a very careful ethical and legal review.
Beyond being in favor of occasionally “intervening”, I would advocate that the community generally be prepared to alter the shared state in order to prevent harm to individuals or organizations.
Tools and governance processes need to be in place.
Still, I understand and appreciate that there is a widespread expectation for immutability in Ethereum. This is a special property which has many measurable benefits. However, immutability of information systems is unprecedented in human history. This property does not absolve us of moral or legal responsibility for what happens in the Ethereum network. It may be dangerous to enforce this immutability absolutely, or simply to be unprepared when we as a community must suddenly act to alter the shared state.
Perhaps with EIP-999 and other ether recovery EIPs we can attain and manage an extremely low mutability in our system instead of assuming immutability.
I oppose this EIP, and I oppose the way discussion has left GitHub and is now on this new site.
Ethereum is as immutable as you design it to be. The Parity contract was designed to have an immutable reference to a library that got deleted. What more is there to say?
Should someone get special treatment because they have a lot of money? I don’t think so. If this EIP goes towards a production state I will be the first person to maintain an Ethereum blockchain that has not been hardforked to restore the parity library.
Decentralization is not an end in and of itself but a means to eliminate the risks that come with a centralized system. Specifically, decentralization provides the means to protect against centralized control that would otherwise threaten an individual’s right to control his or her own assets. Decentralized blockchain systems have value as a tool because they can protect private property rights in a way that was not previously possible. However, to the extent these new systems introduce new ways that prevent owners from accessing that which they own, they fail to be useful.
Also, the blockchain is not immutable, nor would it be of any use if it were. The current state of the blockchain mutates with every transaction. However, client logic is designed to prevent unauthorized changes. An account owner authorizes the client application to perform actions on his or her behalf by signing transactions, thus proving their ownership and intent to mutate their portion of the blockchain state. To be clear, owners grant permission to the client to modify the blockchain state on their behalf, not the other way around.
How, then, should a decentralized system behave when users are prevented from controlling the assets they own?
Proof of ownership and intent are of primary importance. If ownership and intent can be demonstrated (e.g. through signed messages, data on chain), what grounds do we have to prevent owners from controlling their assets? Why should we sacrifice the ends in support of the means?
But how much is occasionally? What schelling point are you advocating?
The reason “immutability” is popular, is because it’s an exceptionally good schelling point.
If you don’t have an equally good schelling point to offer, I don’t see how the community can be be prepared to alter shared state, no matter what harm might be the consequence.
Immutability is a far simpler schelling point. By choosing to manage low mutability we do incur costs and risks.
Perhaps a scheduled intervention should be so rare as to be newsworthy. This way, users can expect to a well-publicized notice about a proposed intervention that may affect them, and plenty of time in which to voice their concerns.
It may be appropriate to set the bar very low for how much individual damage of losses would oblige an intervention. If 10,000 people experience a very small loss correctible by shared state alteration, and performing a recovery has a very low cost in effort and risk to others, the only requirement may be ensuring due process and well-publicized notice.