EIP-999: Restore Contract Code at 0x863DF6BFa4

fund-recovery
#21

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:

  1. 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.

  2. 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.

4 Likes
#22

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.

Initial feedback about this website
#23

I am also against this proposal as it sets a precedent that I don’t think should be set.

4 Likes
#24

"I’m strongly against this EIP because:

the EIP doesnt improve the protocol

the EIP doesnt fix a bug in the protocol

the EIP doesnt fix a problem which is a economic threat to the complete ethereum ecosystem (like the dao fork did)"

credit to u/alkalinegs on Reddit. My feelings exactly.

8 Likes
#25

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.

3 Likes
#26

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.

2 Likes
#27

im strongly against this EIP.

2 Likes
#28

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.

6 Likes
#29

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.

2 Likes
#30

In my opinion…

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?

9 Likes
#31

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.

2 Likes
#32

How much money do you need to lose for it to be news?

1 Like
#33

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.

4 Likes
#34

I oppose this EIP.

For Ethereum platform to retain its value proposition retro-active irregular stage change should not be institutionalized or pushed through unless the entire platform is in jeopardy. EIP should be for protocol improvement only, not for retro-active correction of a selected sub-set of errors that have been made by some vested interests.

I believe funds currently locked would have benefited the ecosystem & good intention of EIP-999 proponents but can’t say the same about future actors that will try to go down that path again.

Internet services got hacked zillions on time and the internet is still being used. Planes crash every now and then but the airline industry has been flourishing.

Work should be done to make Ethereum / DLT tech much safer and usable doesn’t equate to irregular retro state changes should be made in this specific situation. There are plenty of other ways to make DLT much safer:
Solution 1: Mutualisation of risk: Companies & ICOs can create common issuance pools to cover part of the loss when missteps are made.
Solution 2 - Innovation at large: Formal verification, develop better practices, etc.

5 Likes
#35

Do you think it is reasonable we will be able to restore any and all lost funds, including a single dollar in a failed testing application? No? I agree, that would be completely unworkable. So there would need to be some kind of cut-off what will be restored and what not. This is the dangerous part. Who will decide what should be restored and what should not? How do we prevent these entities from being bribed or extorted? Again, a blockchain where extortion and bribery is possible is not useful to me.

And that is not the only issue with that. There are more nuanced and indirect consequences of such a system. The fact that only some funds will be restored, because they are worthwhile (hundreds of millions vs a single dollar) means there will be a preferential treatment by definition. And this will bring forward a “too big to fail” mentality. Assume for a moment there is party A that runs a smart contract for multisign wallets and is the largest by far. Then party B comes with a new smart contract for multisign wallets. People like how it’s used, however, why should you use this new smart contract that is dealing with much less funds? Due to preferential treatments and “too big to fail” mentality it would be better to use an older, perhaps even inferior version, simply because it is dealing with larger amounts of money and hence in the event of lost funds, there is a greater chance they will be bailed out. This would then be a very strong force that leads to monopolies (centralization) and uphold these monopolies.

This “too big to fail” mentality reminds me one thing: Banks. And not in a good way. Please, for the love of Blockchain, let’s keep such a mentality away from Ethereum. We need real, workable and sustainable solutions: Formal third party code audits. If Parity had done their due diligence this would never have happened. And I agree, even with formal audits, things like these might still happen. So let’s solve this in a fair way: Insurance. Decentralized insurance funds could easily work for insuring against these kind of code bugs. And they’ll bring about loads of other positives: They will probably enforce code audits, or they refuse to insure a smart contract. They can be used by large parties, but also by smaller parties, hence no preferential treatment. And most importantly, disputes will be handled between the insurance fund and the affected party, instead of being handled at Ethereum’s base layer, which brings decreased immutability for everybody.

3 Likes
#36

I fully agree. What’s the point of making this mistake, and not learning from it, but adjusting one of the key principles of the technology? Seems like a step in a very bad direction…

#37

@maurelian this is definitely not how decisions are made. Most of the people at the core dev meeting know how to ignore the noise and listen to the distinct arguments. The ones that don’t know how to do that are generally overruled by those that do. Just because people all are making a lot of noise doesn’t mean the noise matters. If you have a novel argument to propose, or don’t believe a particular argument has been heard/addressed, certainly add it! But if you are just joining in the shouting your original strategy is the right one.

1 Like
#38

@fubuloubu There is active discussion about how to potentially change the governance process elsewhere in this Discourse group. If you are interested in the topic, I encourage joining in those other discussions! This EIP is not the right place to advocate for changes to the governance process though, and any attempts to do so will likely result in your voice not being heard (because it is the wrong place to advocate for changes in process).

#39

I disagree, this EIP and others like it is describing a Governance problem. Basically, we need to set a very strong signal one way or the other how to handle this situation of thing so that either we have a good process or recommendations like these stop getting made.

I appreciate you trying to ensure that my voice is heard in the right place, but I simply disagree with you here that this is not a governance issue.

1 Like
#40

I am working on efforts for both these regards (standards and insurance) and I agree that they will reinforce each other and improve smart contract design overall.

I also hear you on the point that enabling even a rare recovery effort would enforce a too big to fail mentality, and that’s definitely not what anyone wants. It’s the whole reason we’re building stuff like this!

I worry that such an unforgiving environment will also weed out smaller actors from producing innovation, but you definitely can’t have both and I think erring on the side of immutability is the best decision, thank you for swaying me that way again. Any sort of recovery process can be corrupted and that’ll get us into the same mess that we’re in now with traditional systems.

Question is, how do we stop these proposals from continuing to be made?