EIP-156: Reclaiming of Ether in common classes of stuck accounts

[5chdn]

Closes #156

I'm stepping up as champion for EIP-156. Kindly paging @vbuterin.

Included proposals:

• This specifies 156A (aka "v1" - Contracts without code).
• This specifies 156B (aka "v2" - Incorrectly computed addresses).
• This specifies 156C (aka "parity multi-sig library")
• This specifies 156D (aka "cosmos crowdsale-bug")

Not included proposals:

• This does not specify "v3" as I do not see any or improvements advantages over "v2" (but feel free to prove me wrong).

Notes:

• I suggested to include 156A,B in the Constantinople hard-fork and renamed the variables accordingly.
• I suggested a one-year claim period for 156A, renamed the variable subsequently, and recommended two million blocks.
• This is early work-in-progress, I still need to catch up with the full discussion in Reclaiming of ether in common classes of stuck accounts #156, but I feel this draft needs to be out early. Done.
• I'm happy to append this proposal by 156C and 156D as discussed in the linked comments if this is generally desired and technically well-specified. Kindly paging @holiman and @ebuchman. Done.

Let's try to split the discussion to keep an overview: general concerns and political implications go into #156; technical aspects go into #803 (here). Thanks.

---

Disclosure: I have no assets in any locked accounts. Work on this EIP is a personal effort and not in the scope of employment by Parity Technologies.

[holiman]

The cosmos crowdsale bug has a working implementation; see #156 (comment)

[5chdn]

@holiman right, thanks. I started adding this https://github.com/5chdn/EIPs/pull/2/files#diff-7beb254da2e418cbc42ca6ba03b1c3e6R57

Need to expand on the calculates the corresponding cosmos address part, yet.

[holiman]

This is the part which calculates the cos address:

    function testCosRecovery() constant returns (bytes20){
        bytes memory a = hex"02D7485091B95C158EEEC8ED2E248F7164BE5DF0956583DB3BB99F326390081CF8";
        var s = sha256(a);
        var b = ripemd160(s);
        // returns 0x4fb8fab66ef33955f10d59b9b86183148858dbce
        return b;
    }

And a represents the compressed pubkey.

[gcolvin]

I've put a link for discussion here as well. https://gitter.im/ethereum/ether-recovery?at=5a3a88c119147ac3231ae130

[MicahZoltu]

This EIP adds a bunch of really unnecessary complexity. If recovering lost ETH is desired, then we can simply include a list of accounts that need to have one-time state transitions applied to them as part of a hard fork. The Ethereum client implementation complexity of one-time state transitions for a certain set of accounts is way lower than adding a new set of temporary EVM rules.

If desired, the logic proposed in this EIP could be used to decide which accounts get added to the list and which don't, and that logic can be executed off-chain and validated by anyone prior to the fork.

[gcolvin]

Makes sense to me @MicahZoltu. What transactions besides the ones that fit the rules here might be on the list?

[pirapira]

A space is missing between - and 156A.

[pirapira]

The format of the date is unusual.

[pirapira]

Aren't we using the v values for replay protection?

[pirapira]

Can declareEmptyContract (or declareLowercaseHexAddress) be called after withdraw() again?

[pirapira]

Can new future Ether be created after the hard fork?

[tjayrush]

Please include disclosure text with your posts. It's impossible for less-technical people to fully understand implications of comments without explicit disclosures of your interest in this issue.

Disclosure: no locked ether in any accounts

[MicahZoltu]

A sound argument will be sound regardless of whether the person making it benefits from what they are proposing. Knowing who has stake and who doesn't is more likely than not to lead to people not listening to sound arguments because they believe the author is "biased". I would like to keep biases out of this discussion as much as possible (it is already massively biased as it is).

[MicahZoltu]

@gcolvin Sorry for not replying sooner, I missed your mention. The specific rules I think are up for debate and we should have a forum for discussing them. My primary concern is bloating Ethereum codebase and solving this problem in a complex way when we have an incredibly simple way to solve the same problem (off-chain). Personally, I would start by just saying something like:

If you can prove to a reasonable human that you have stuck Ether (that can provably not be retrieved) then your address/amount gets added to the list. This would account for everything this EIP accounts for, the Parity issue, the issue where the token sale posted the wrong address to their website (bad checksum), ETH sent to account 0, etc.

Others can review submissions and if anyone has a valid objection (e.g., "that isn't actually stuck" or "you can't prove that is stuck") then the address/amount isn't added to the list.

If someone wants, they can write a script that compiles a bunch of these automatically, for others they are "well known" like the Parity multisig bug and such.

[montagist]

@tjayrush I think the disclosures make sense/can be helpful, but I disagree that their absence makes understanding "impossible" for non-technical people or anyone else.

[gzduan]

Can add a variable in the account, if it is 1 means someone have used the private key of this account , by default, all the variable of new account is 0, if someone used the private key of the account, this variable is automatically into 1. Otherwise the variable will always be 0, if you accidentally sent many tokens to the account that variable is 0 , the system will be in after a period of time, such as 3 years ,if this account still didn't have the records of using the private key, in other word,the variable is still 0. The system can identify the account as a black hole account and the money will be automatically returned.
The mistake of sending money to the black hole address, which is unavoidable, will continue to happen now, and this is the defect of the Ethereum network,
This similar to activate an account,if there have the record of using private key on the blockchain, the account will be automatically activated and will not returned the eth after received the eth three years , the use of paper wallet does is restricted, because there must be activated account operation, but this only to new accounts which private key never used by people , maybe paper wallets are not a necessary a way of storing tokens, Cold wallet signature can be a good choice, can use the private key offline and ensure absolute safety.
Put the tokens sent to the a black hole accounts always happen to us, on the one hand block chain technology ensures the property safety of people, but the careless operation is so despair to ethereum users .the proposal can effectively recover the eth that sent to a black hole account , at the same time ,it also punished the careless users, Because they have to wait at least three years to get the money they lost because of their mistakes.
It's like you have to bind a phone number when you use Facebook account.

[5chdn]

Closing due to the heterogeneous nature of this proposal (156 A, B, C, and D) in favor of EIP #867. Each sub-proposal of the current EIP #156 version could be its own ERP if EIP #867 is accepted.

If EIP #867 is rejected, I don't see much potential for EIP #156 either.