Modify Contract Code at 0xfb4f9E002763b9D8A48EFcE8AB8A33e4d3bC9efC

[zjunyi]

EIP:
EIP Title: Modify Contract Code at 0xfb4f9E002763b9D8A48EFcE8AB8A33e4d3bC9efC
Author: Zheng Junyi
Type: Meta
Status: Draft
Created: 2018-04-24

Simple Summary

An old contract had 4 ETH locked up due to a bug in the code published on ethereum.org. The fund is provably mine, and completely unmoveable, and the bug renders an insignificant amount of Ether inaccessible.

Abstract

An early version of the contract at https://www.ethereum.org/crowdsale had a bug on line 35, where balanceOf[msg.sender] = amount; which causes multiple contributions from the same address to be lost. I propose the addition of a function calling selfdestruct, changing the contract code at the address 0xfb4f9E002763b9D8A48EFcE8AB8A33e4d3bC9efC which it was deployed. This will allow the release of the funds to the beneficiary of the smart contract.

Motivation

This proposal is necessary because the Ethereum protocol does not allow the redeployment of contract code on a defined address, and there is no other simple way to enable the affected users and companies regaining access to their tokens and Ether. In opposite to previously discussed proposals, this will not change any EVM semantics and tries to achieve the goal of unfreezing the funds by a single state transition as specified in the next section.

Also, this was deployed 1 years and 3 months ago, so can be said to be an early participant in the exciting adventure that is Ethereum. With a coinvote of 48% in favor of EIP 999, I assume a sizeable minority of Ethereum ecosystem do not wish to punish a human error with irrevocable loss of funds.

In fact, just like EIP 999, this 4 ETH recovered will be used for pushing forward development in the space, via a donation to the Ethereum Foundation, which is also a registered non-profit, and likely cannot spend money on lambos.

I've completely no idea how many people deployed the contract on main net like me, though I suppose a quick bytecode search might reveal it, but I'm really hoping it's not the absolute amount of ETH that matters, but the principle of recovery.

Specification

The code at the address will be replaced with one containing the following function

function boom() { selfdestruct(beneficiary); }

Rationale

The approach involves minimal changes to the state, and does not break the existing EVM.

The total supply of Ether is neither changed nor does this proposal require the transfer of any tokens or assets including Ether. It is assumed that this change is aligned with the interests both of (A) me and (B) other people who actually deployed official test code on the mainnet. Lastly, the client-side implementation cost of this proposal is estimated to be low, involving a single change to the state.

The argument for Ethereum Recovery Proposals is really an argument for property rights. In this case, property rights are in conflict with immutability. - @MicahZoltu

Blockchain history is immutable, blockchain state is not. It's an important distinction. - @fredhrson

Backwards compatibility

This proposal introduces backwards incompatibilities in the state of the contract at 0xfb4f9E002763b9D8A48EFcE8AB8A33e4d3bC9efC. The Ethereum protocol does not allow the redeployment of code to the same address. To implement this on the Ethereum blockchain, it is recommended to add the necessary state transition in a future hard-fork at a well-defined block number, e.g., CNSTNTNPL_FORK_BLKNUM for the Constantinople milestone which is supposed to be the next scheduled hard-fork on the Ethereum road-map.

Implementation

A sample implementation will be developed if the proposal goes through.

[MicahZoltu]

I recommend signing a message with the private key that controls the contract at 0xfb4f9E002763b9D8A48EFcE8AB8A33e4d3bC9efC. That says something like, "I approve #1030".

I also encourage following the process laid out in #867, which provides a good template (IMO) for laying out an EIP like this.

[zjunyi]

Good point, I didn't realise the ERP was successfully adopted, given that it was stalled for a while.

That said, I don't really think this justifies a state change and the corresponding bloat it adds to the client. But I'm in favour of a good discussion on where the line is, and having another extreme case (4 ETH recovery) might be good for deciding what should be saved and what shouldn't.

[Arachnid]

FYI, this isn't an actual EIP - if you want to write one you need to send a PR according to the guidelines in the readme and EIP 1.

Also: You'd need to specify things at the EVM level - you can't unambiguously say "add this function to the contract".

[zjunyi]

Understood, this is just a draft for discussion, which is why I placed it in issues. I'm just kinda.. surprised no one is jumping in asking how they can also get their ETH back.

If the Eth Recovery Proposals goes through I'll format it accordingly and list it there instead. I don't suppose we need an EIP after all?

[bradleat]

Shouldn't you be in favor of more people, not just those well-versed in the EVM's inner workings, submitting such proposals.

[MicahZoltu]

@zjunyi The ERP process isn't finalized, it is just a draft, but I believe it is good advice and a good process to follow none the less, and the most likely process by which you'll get this pushed through.

An issue is the correct place if you want to start with discussion, so far you are following the recommended path quite well. Kudos for you for doing your homework. :D

The ERP process would make it so changes like this are incredibly low-cost for client dev teams, because they will (assuming they engineer for the ERP process) have a generalized mechanism for dealing with this class of problems. Personally, I think that the ERP process provides a high enough barrier to entry that people will self-select out when the reward (amount being recovered) is too low. Basically, the amount of work the author has to put in is way higher than the amount of work client developers have to put in for each recovery, and that is how we draw the line, by letting users decide whether it is worth it to them or not.

If 4 ETH is worth it for you to go through all of the trouble of properly defining an ERP (including the required scripts, arguments, proofs, etc.) then somewhere below 4ETH is where we would draw the line. Client developers would only need to verify your scripts/proofs (which should be easy for them if your ERP is of sufficient quality) and then include the state transition you supply in JSON format in the next hard fork.

[MicahZoltu]

@bradleat It is perfectly acceptable for someone to find (hire) a third party to draft the ERP for them and handle the technical bits. However, we do want the process to remove as much cost from the EIP editors and client developers as possible, which means someone else has to do the technical work.

[ghost]

@MicahZoltu The ERP process is not an accepted process - he should not be following it and you should not be recommending it. In fact, it has been roundly rejected by the community.

[MicahZoltu]

The ERP process is currently the best recommendation we have (IMO) for recovery proposals. It minimizes the work required by the client developers, while providing equal opportunity to anyone willing to put in the effort (no preferential treatment to certain users).

While I recognize that there are some people who aren't in favor of any recoveries, none have been put to the test yet (meaning none have been proposed in a client update) so we don't actually know how the community feels yet.

[bradleat]

I'm of the opinion that people who want a recoverable token should build it as an erc-20 wrapper. Call it governed-token and define some sort of human intervention processes (perhaps with a pseudo-legal framework or arbitration) for reversing transactions made with that token.

Basically the idea is you can send any erc-20 token to the governed-token contract and then proceed to move the tokens around the wrapper's accounting system. However, the accounting system would have room for some sort of judgement process.

Something like https://kleros.io/ could power it. @clesaege

[MicahZoltu]

The ERC-20 wrapper could just as easily have a bug. In fact, I would argue that due to the complexity of authoring yet-another-governance-layer, the chances of some layer-2 solution having a bug are higher than layer-1. Thus, we don't really solve anything by doing this.

Also, for many classes of inaccessible ETH, the user could be impacted when moving ETH into/outof the token (e.g., fat finger the address, forget to set the recipient, etc.).

[bradleat]

@MicahZoltu it could have a bug. However, Ethereum doesn’t have a well defined governance layer outside of developers will write code and users will decide to run that code (or not).

Fat fingering aside, I am sure many people who want to be secure from theft, mistakes, or scams would enjoy a token with a governance layer built into it. The beautify of building a wrapper is that those who want it may opt-in to the layer. There could be many competing layers; a market place for governance layers would be able to organically surface a better system than endless EIP or ERP could.

The wider Ethereum community should not be involved in hand holding mistakes made with individual tokens or addresses, but instead should be focused on the protocol. A well audited governance layer avoids this problem and allows people to self-select which group (hand held or wild ones) they wish to belong to. Moreover, we decrease the risk of contentious hard forks.

[MicahZoltu]

As I have been arguing elsewhere (so sorry if you have seen this one before), the only governance process that I think really matters/is effective is one of forking. Building a forking governance layer on top of a forking governance layer feels redundant. I would be pretty strongly against a democratic governance layer built on top of the current forking governance layer because ultimately, the only way users have to opt-out of a democratic system is to fork, so we are right back where we started with people forking Ethereum.

I'm far less scared of a fork than I think a lot of people are. I think forking should be easy and should happen fairly regularly. It is unlikely that, as the userbase of Ethereum grows, everyone will continue to agree on everything and so if forks aren't happening that to me signals that forking is too hard. Bitcoin has seen a number of forks lately, and I think this is healthy. While I still think Bitcoin has a ton of problems shared across all of the forks, I don't think its forking is the problem.

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.