Reclaiming of ether in common classes of stuck accounts

[vbuterin]

The discussion link has been migrated to https://ethereum-magicians.org/t/reclaiming-of-ether-in-common-classes-of-stuck-accounts/16111

Specification (v1)

The below is only usable between blocks FORK_BLKNUM and FORK_BLKNUM + EFFECTIVE_DURATION (both TBA).

If the v value of a signature is (strictly) greater than 1024, then calculate the sender as follows:

1. Let s be the sender computed according to the normal algorithm, using 27 as the v value if the provided v is odd, and 28 if the provided v is even.
2. Let the actual sender be the address that a contract would be created at if its sender is s and the contract creation nonce is floor((v - 1025) / 2).

Transactions with v values strictly greater than 1024 are only valid if the sender account is nonexistent or its code is empty.

If the v value of a signature is 1023 or 1024, then calculate the sender as follows:

1. Let P be the public key computed according to the normal algorithm, in the 64-byte packed form that is normally hashed to determine the sender address, using 27 as the v value if the provided v is odd, and 28 if the provided v is even.
2. Let the actual sender be the last 20 bytes of the sha3 of the lowercase non-prefixed hex encoded form of P instead of the binary raw P itself.

Specification (v2)

Create a solidity contract with the following functions:

• declareEmptyContract(index): computes rlp.encode([msg.sender, index]); if there is a contract at this address with ether and no code, then the contract saves a record that this contract has been checked, and sends an equal amount of "future ether" (an ERC20 token) at that account.
• declareLowercaseHexAddress(pubkey): checks sha3(pubkey) % 2**160 == msg.sender; then checks that sha3(pubkey.encode('hex')) % 2**160 has ether; if it does, then the contract saves a record that this contract has been checked, and sends an equal amount of "future ether" (an ERC20 token) at that account
• withdraw(): deletes the msg.sender's future ether, and sends it an equivalent amount of ether.

The hard fork would increase the future ether contract's balance by an amount equal to the total quantity of extant future ether.

Specification (v3)

Follow v2, but distribute the future ether on a Casper testnet. Then, later have a single step that converts both Casper ether and ethereum 1.0 ether into ether as part of the Serenity hardfork.

Rationale

This allows for users with ether or other assets in common classes of "stuck" accounts to withdraw their assets. The first case covers contracts that are accidentally created with no code, as well as some losses due to replay attacks where a contract was created on ETC, funds sent on ETH but the contract not created on ETH; the second case covers losses due to an old ethereum javascript library that incorrectly computed ethereum addresses. Note that in all cases, the "rightful owner" of the assets is obvious and mathematically provable, and no user is being deprived of any assets, and this proposal provides no explicit favor to any single account, user or application.

It is understood that there may be a risk that this proposal will be viewed controversially as it is in some sense a "rescue" rather than a "technical improvement", even though it is arguably much less intrusive than previous such proposals for the reasons outlined above; the proposal is created in order to allow community discussion and debate and does not signify full endorsement.

[jespow]

Speaking on behalf of Kraken, I would characterize this more as recompense than rescue. We did take on some not insignificant losses as a result of the mentioned bug in the old Ethereum javascript library. At the time, losses were covered out of Kraken's pocket to protect our clients. We would greatly appreciate the ability to recover the funds tied up in the incorrectly computed addresses. Thank you for this proposal.

[trapp]

Here are some reports of affected users and implementations:

• https://www.reddit.com/r/ethereum/comments/48rt6n/using_myetherwalletcom_just_burned_me_for/
• https://www.reddit.com/r/ethereum/comments/47nkoi/psa_check_your_ethaddressorg_wallets_and_any/
• https://www.reddit.com/r/ethereum/comments/3vfaob/bug_in_ethereumjsutil/

[Smithgift]

Back when the DAO hardfork was debated, this category was brought up as a thing too difficult to fix therefore (INSERT CONCLUSION HERE). I'm glad we're considering fixing it now.

[cdetrio]

@jespow @trapp If this spec were to be adopted so that Kraken's losses could be recompensed, would Kraken be willing to in turn cover the losses of users affected by the not safe enough ReplaySafeSplit contract?

[trapp]

@cdetrio I don't think we can compare the two issues with each other.

a.) The ethereumjs-lib did have a bug and did not work as intended.
b.) ReplaySafeSplit does not have a bug, it works according to the interface. It has two mandatory address parameters, you have to specify both when calling the contract. You cannot omit one.

When you specify 0x0 as target address then that is a user input error. When your GUI defaults to 0x0 when you leave one of the two empty, then that's an issue with the GUI. I'm not aware of any GUI that actually does this but see a similar issue in Mist: ethereum/mist#1128

The "fixed" version has an additional check for 0x0 as target address which helps with this specific case but still allows other nonsense addresses like 0x1, 0x2 etc. You cannot fix an issue like that on the contract level, the best place is the GUI (like address checksums).

c.) I also think it's offtopic here since the ReplaySafeSplit contract was not created or published by Kraken. The bug in this thread does not only affect Kraken, I would even say that the MyEtherWallet users lost a more due this bug compared to Kraken. Kraken just came forward in support for this initiative.

[neeeeeeext]

Another thread related to this EIP:
https://www.reddit.com/r/ethereum/comments/5rd4co/ethereum_wallet_sends_to/

[GriffGreen]

Maybe I'm missing it in the complexity... but if someone generates an account offline, for let's say a paper wallet, and then sends to it but claims it was an accident. What is to stop that person from doubling their ether if this EIP is implemented?

[GriffGreen]

@LefterisJP and @jbaylina figured it out for me!

http://ethereum.stackexchange.com/questions/760/how-is-the-address-of-an-ethereum-contract-computed#761

The contract address is deterministically computed from the address that created it :-), so the paper wallet trick wouldn't work.

[axelay]

Posting on behalf of QuadrigaCX, we would like to see an amendment to this proposal in order to reclaim trapped Ether on contracts that have no ability to send.

Not only to rescue some past mistakes but also thinking about providing a safety net for the future. Even though progresses have been made in Solidity to ensure return of the funds, there could still be a chance of Ether becoming trapped.

[Souptacular]

Hi @axelay,

there could still be a chance of Ether becoming trapped

What are the other ways ether can become trapped? Are you meaning functions that are payable, but do not have a means to get the ether out of the function?

Also, please reach out to me at hudson@ethereum.org [PGP 028D 1459 247B 9596 if you prefer] so I can verify that you are representing QuadrigaCX officially. There have recently been people in the community that seem to be speaking for QuadrigaCX, but are not actually employed or represent QuadrigaCX in any way.

Edit: Confirmed that @axelay is representing QuadrigaCX.

Thanks!

[mjmau]

I created a tool to scan for the "ether stuck in empty contract" case. It finds about 3500 ETH in almost 300 empty contracts. I'm not sure I understand the edge cases and welcome any review.

https://gist.github.com/mjmau/e073091446751b08762c8c65ae13a37d

[netpro2k]

we would like to see an amendment to this proposal in order to reclaim trapped Ether on contracts that have no ability to send.

Wouldn't this be problematic for contracts that are intentionally "burning" ether by locking it up? Sure this could be done in the future in other ways (sending to a dead address) but I would be surprised if there didn't already exist contracts for which this would be an issue.

[holiman]

Wouldn't this be problematic for contracts that are intentionally "burning" ether by locking it up? Sure this could be done in the future in other ways (sending to a dead address) but I would be surprised if there didn't already exist contracts for which this would be an issue.

Intentional burns are usually sending to 0x or some 0xdead address. Intentionally locking the ether up in a 'dead' contract to which there is actually a key seems very unlikely.

[Arachnid]

Posting on behalf of QuadrigaCX, we would like to see an amendment to this proposal in order to reclaim trapped Ether on contracts that have no ability to send.

Do you have a technical proposal on how that could be achieved?

Devising a fair rule for this seems particularly problematic, since QuadrigaCX didn't even deploy the contract in question.