Skip to content
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

Restore Contract Code at 0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4 #999

Merged
merged 25 commits into from
Apr 16, 2018

Conversation

5chdn
Copy link
Contributor

@5chdn 5chdn commented Apr 15, 2018

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

EIPS/eip-999.md Outdated
author: Afri Schoedon (@5chdn)
discussions-to: https://ethereum-magicians.org/t/o-be-announced/999
status: Draft
type: Standard Track
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be "Standards Track".

EIPS/eip-999.md Outdated
eip: 999
title: Restore Contract Code at 0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4
author: Afri Schoedon (@5chdn)
discussions-to: https://ethereum-magicians.org/t/o-be-announced/999
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs replacing with an actual URL.

@sandakersmann
Copy link
Contributor

The community has rejected bailouts and developer corruption.

@Arachnid
Copy link
Contributor

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
Copy link

Mushoz commented Apr 15, 2018

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

@jdetychey
Copy link

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
Copy link
Contributor

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
Copy link

peterkelly commented Apr 15, 2018

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
Copy link

gskapka commented Apr 15, 2018

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
Copy link

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
Copy link

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
Copy link
Contributor

seibelj commented Apr 15, 2018

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
Copy link
Contributor Author

5chdn commented Apr 15, 2018

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

@seibelj
Copy link
Contributor

seibelj commented Apr 15, 2018

@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
Copy link

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
Copy link

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
Copy link
Contributor

3esmit commented Apr 15, 2018

Great, finally a solution.

@x-ETHeREAL-x
Copy link

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
Copy link

@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
Copy link
Contributor

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

@PeterFarfan
Copy link

A second time?

@bwheeler96
Copy link

@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
Copy link
Contributor

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 Arachnid merged commit e30becf into ethereum:master Apr 16, 2018
@Arachnid
Copy link
Contributor

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
Copy link

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

@bwheeler96
Copy link

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

@5chdn 5chdn deleted the a5-eip-999 branch April 18, 2018 11:37
@mryellow
Copy link

Discussions to: ethereum-magicians

No thanks.

@mislavjavor
Copy link

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
Copy link

krtschmr commented Apr 23, 2018

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

Arachnid pushed a commit to Arachnid/EIPs that referenced this pull request May 2, 2018
…thereum#999)

* Claim a random number

* Add specification

* Add rationale

* Improve wording

* Improve formatting

* Improve wording

* Specify the account values for balance, nonce, code, and storage

* Be more specific about a hard-fork

* Add poc implementation for Parity

* Improve formatting

* Improve formatting

* Make sure the total supply will be unchanged.

* Point to relevant changes in chain spec.

* Remove contracts/ethereum#74 code from the proposal.

* Use the old but patched library

* Highlight differences to the initially deployed contract

* Add code and storage for the stateDiff

* Update resources

* Update resources

* Add correct discussion URL

* Standard Track -> Standards Track

* Link the PR for Parity

* Rationale on unchanged Ether supply

* Split specification alternatives via bytecode vs. codehash
@Neurone
Copy link
Contributor

Neurone commented Jun 10, 2018

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
Copy link

Exactly consensus agreed not to support this EIP.

@cupOJoseph
Copy link

cupOJoseph commented Jul 16, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.