Restore Contract Code at 0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4

[5chdn]

Hallo! This proposes to restore the code of the WalletLibrary contract at 0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4 with a patched version that can not be claimed or killed.

Link to read the proposal document: eips.ethereum.org/EIPS/eip-999.

Discussions to: ethereum-magicians.org/t/eip-999-restore-contract-code-at-0x863df6bfa4/130

[Arachnid]

Should be "Standards Track".

[Arachnid]

This needs replacing with an actual URL.

[sandakersmann]

The community has rejected bailouts and developer corruption.

[Arachnid]

This meets the requirements to be merged as a draft. Do you want it merged immediately, or left open for discussion? (Personally, the former seems cleaner, so as not to split general discussion between this pr and the discussion thread.)

[Mushoz]

Hardforking to restore bugs is a slippery slope and will tarnish Ethereum's reputation permanently. I strongly oppose this EIP.

[jdetychey]

This EIP is straight forward compared to the complex immutability changing process proposed before.
IMHO:

• hardforking will most certainly lead to some sort of standardized recovery procedure
• not hardforking will send a strong signal that such a procedure is not an option (yet?) for ethereum developers

[Arachnid]

That said, I've proposed that if we can make a general solution for restoring killed contracts that can apply to other cases without risk to immutability. Essentially my thinking boils down to this: A contract can be restored if and only if it is restored with the exact same code by the account that originally created the contract. This would give the victims of the parity hack the ability to recover their funds provided the person who deployed the library contract can support deploying/redeploying the contract as needed.

This has been discussed in the past; there's no way to do this without breaking the way selfdestruct works in ways that could break other peoples' expectations around contract security.

[peterkelly]

This is the wrong level of abstraction at which to address the issue. The more general case is the question of whether or not it is desirable to have a system which allows developers to deploy code to production but makes it impossible to fix bugs in said code.

I don't have an answer to this question, and it's a complex and controversial one. But the kind of problem this EIP attempts to address will inevitably happen again. It would be much better for consensus to emerge about whether or not facilities to revoke/update contracts should be built in to the platform (for contracts which themselves haven't catered for that possibility in advance), rather than handling it on an ad-hoc basis for specific contracts.

[gskapka]

Whatever the answer ends up being to a problem like this, it needs to be general and applicable to any contract going forward. Any other option is against the egalitarian nature of the chain. Because of this, I don't see a resolution that both recovers lost funds AND is in the best interest of the rest of the community.

Allowing code resurrection after self-destruction will introduce myriad other issues, especially if it resets the state of the contract. The potential for abuse is large. As such, I don't agree with altering the current way self-destruct works in the EVM.

And so since this EIP includes BOTH of my concerns, ie, allowing resurrection AND allowing it for only one privileged party/contract, I am against the proposal.

[ryanberckmans]

I am against this because immutability is the defining feature of Ethereum and driver of the network's value. Very sorry to those who lost funds in this incident.

[agermain]

Like someone mentioned earlier, I think general solutions should be the main focus of discussion if anything, attempting to rescue the funds by hardforking is, in my opinion, the wrong approach.

Immutability is one of the most valuable things Ethereum currently has, let's not damage it.

[seibelj]

If I lose 1 ETH and can prove I lost it and no one else claims it, there should be a system and process for me to get it back. If you keep letting arbitrary EIP's go through to help privileged people, then the hypocrisy is blatantly obvious and it leads to contention and drama.

I support giving Parity wallets their money back if I can also get my money back when I make a mistake.

[5chdn]

@apg258 @seibelj - Thanks for sharing your thoughts. Have you looked at #867 yet?

[seibelj]

@5chdn What I'm getting at is that this EIP should be closed unless a standard for everyone is approved. So until that happens, this cannot be merged as it's unfair. I am unsure whether I support letting everyone alter history to benefit themselves, the community can decide. But if the community can't agree on letting everyone change the blockchain when needed, then this EIP should be closed.

[himalayajung]

Ethereum should really try to devise more general purpose solution for unforeseen events like this. I feel that handling fund recovery on a case by case basis is against its philosophy.

[AlekseyKorzun]

The author has a strong, well-prepared case. Instead of trying to discuss this 'later,' perhaps a more reasonable option is to allow this to go through and try to solve this problem.

That's how a community should work. It's not black and white. There is a technical side, and there is a people side. Try to understand both for a minute.

The idea of doing a hard fork to recover funds is ridiculous, but that's not authors fault. It's yours.

[3esmit]

Great, finally a solution.

[x-ETHeREAL-x]

This is a specific request to restore a single self-destructed contract? How many people have made mistakes that cost them ETH? Allowing case-by-case proposals for mistake reversals is a terrible idea and opens up all kinds of concerns about picking winners and losers (and who gets to pick). When any person or group is able to pick winners and losers, you inevitably get corruption, bribery, etc. This would set a terrible and dangerous precedent.

[bwheeler96]

@Arachnid can you elaborate on this? I understand that it would be a breaking change to the way selfdestruct works, but what kind of security expectations rely on removal of a contract? It makes sense, but maybe if we consider some examples we can make progress on a viable solution

[Arachnid]

@bwheeler96 https://medium.com/@weka/on-paritys-proposed-changes-to-selfdestruct-behaviour-c3f0e5bc0f49

[PeterFarfan]

A second time?

[bwheeler96]

@Arachnid very well written article. It is unfortunate that the contract code is not hashed into the address of the contract. It would be possible to create a recovery while breaking fewer invariants if that were the case.

[fulldecent]

I think #894 should be merged before this PR because #894 meets the requirements to be merged as a draft.

A delay of #894 or a preference for this PR could only be for reasons unrelated to technical acceptability.

[Arachnid]

I've merged this PR to create a draft EIP, as it meets all the requirements for an EIP editor to do so. Because I know this will be contentious, I'd like to highlight a few important points:

• Merging as a draft does not imply approval. Anyone can write an EIP, and as long as it's well formatted and meets a very low bar of soundness, an EIP editor will merge it as a draft.
• This does not mean the EIP is accepted, or that it will be part of a hard fork. That decision is taken at All Core Devs, and ultimately the acceptance or otherwise of a hard fork is up to the userbase, not the EIP editors. The editors will update the state of an EIP to reflect decisions made at all core devs and the state of the chain, not the other way around.
• This is the beginning of the conversation about this EIP, not the end. To avoid fragmenting conversation in multiple venues, please take discussions about the EIP itself to the discussions-to URL, here.

[taoteh1221]

Community governance != ETCv2|ETH-Gold|ETH-Silver|ETH-Private...best of luck, tough call here.

[bwheeler96]

@taoteh1221 yeah that will be the result if this gets merged. Don't get me wrong I'll be fully on board. I think I'll call my fork ETH-Saffron.

[mryellow]

Discussions to: ethereum-magicians

No thanks.

[mislavjavor]

This would set a really bad precedent. While I am extremely sympathetic to all who lost their money in the hack, the damage that would be inflicted to the community far outweighs the loss of access.

[krtschmr]

so, every time when famous devs loose money through a bug that they caused, Ethereum will hardfork to return them the money.

this is 3rd fail of parity and this time they lost money. the other 2 times people lost money.

the vote is completely rigged. what's wrong with Ethereum ? i loose all faith if this is approved.

maybe they paid 10M$ to get this through? nobody knows and we will never know. it opens the door for corruption. Ethereum did nothing wrong. it's a toplayer solution.
if i use JAXX Wallet and tomorrow, JAXX update has a bug and i loose 25M$ ETH - nobody will fork it for me.

wtf....

[Neurone]

To understand why I support this EIP, I expose the premises my reasoning starts from.

• Consensus always wins, the God of Code does not exist (yet). Changing blockchain state is always achieved by consensus, it's already true for every block and transaction. Consensus is expressed by people, and people form a Community around those consensus rules
• EIP is a good enough method to propose changes that require a hard fork. Different methods can be chosen to propose changes to the Community, but EIPs are already used to reach consensus about many different changes in the Ethereum ecosystem (Core, Networking, Interface, etc.). If we need to change something at chain level we need consensus, an EIP sounds to me a good enough method to try reaching such consensus
• A precedent already exists at block 1,920,000 (20th July 2016), EIP779. Almost 2 years ago, because of some bugs in the DAO contract, someone moved 3.6M ETHs (of a grand total around 12M ETHs) from the DAO balance to its own account. After many days of discussion, the majority of the Ethereum Community agreed that the contract didn't acted as intended by the DAO's developers, and it chose to hard fork from the original chain to rescue funds of DAO's investors, zeroing the hacker's balance and giving funds to the original smart contract. This precedent demonstrated that the Ethereum Community tolerates changing the blockchain's state in some specific cases. Ethereum Classic - the original chain - is still there demonstrating that Community matters and consensus mechanisms work
• We can discuss about changing chain's state because of errors in a smart contract. In this community this kind of discussions are allowed, and in case of success a hard fork is admitted restoring something that went wrong. The DAO's hard fork, EIP779 and this EIP999 are here to demonstrate that. And it's very good for me to have two communities that act differently, because I can choose which one is the best for each different use case

About this specific EIP

• This seems to me a very reasonable fix. The DAO fix was very serious, and it changed the state at a very intrusive level: it essentially moved funds from an account - the hacker's one, that has gained those ETHs following the bugged rules of the smart contract - to the DAO's account. This is very far that case: here many people lost access to their own ETHs, but those funds gone nowhere: they are still there untouched inside each multisig wallets, but nobody can use them. And this because a piece of code - a library - some wallets rely on was deleted by the hacker. This EIP will enable those wallets to regain access to their own funds, giving wallet's owners the ability to use those ETHs again

At the end this EIP restores a state of the chain where multisig wallets can work again, no one loses ethers, tokens or whatever and no one gains them. This seems legit enough to me, and this is why I support this EIP.

[PeterFarfan]

Exactly consensus agreed not to support this EIP.

[cupOJoseph]

While I agree with @Neurone reasoning, I think the nature of this is not very blockchainy. We use this tech because there are no takesie-backsies.

Look at every post on twitter vitalik makes, there are scammers pretending to give away ETH. Should we go hunt down every "scammer" account & fake ICO, and undo every mistake transaction made to fix? I feel like the point is that a mistake here is supposed to be a mistake forever. And if you wanted to be able to undo a mistake like that you should use a credit card.

On trust

If you fund a project (like Parity or any other) you are trusting them. If they run away with your ETH or accidentally kill their contract, as in this issues's case that is the result of trust.

I'm voting no for now but am open to talking about is. Maybe the blockchain that we want is one that is sunshine and rainbows, where we the community can help each other, fix honest mistakes, punish bad actors and we can all get along. I think the case now is that the ecosystem needs a crypto-anarchal no takesie-backsies blockchain.