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

EIPS/eip-156.md

@@ -0,0 +1,74 @@
+## Preamble
+
+    EIP: 156
+    Title: Reclaiming of Ether in common classes of stuck accounts
+    Author: Vitalik Buterin, Martin Holst Swende, Afri Schoedon
+    Type: Standard Track
+    Category: Core
+    Status: Draft
+    Created: 2016-1014
+
+## Simple Summary
+This proposal allows for users with Ether or other assets in common classes of _stuck_ accounts to withdraw their funds.
+
+## Abstract
+The first case (156A) covers contracts that are accidentally created with no code, as well as some losses due to replay attacks where a contract was deployed on the Ethereum Classic network (ETC), funds sent on Ethereum (ETH) but the contract not created on the ETH network. The second case (156B) covers losses due to an old Ethereum-JavaScript library that incorrectly computed Ethereum addresses. The third case covers losses due to the self-destruction of the multi-signature library (156C). The forth case covers losses due to incorrectly use of the Cosmos fundraiser tools (156D).
+
+## Motivation
+The Ethereum network is still to be considered experimental and under heavy development. Bugs that cause incorrectly calculated addresses, funding contracts without code, or simply the lack of replay protection should not lead to end-users losing funds.
+
+## Specification
+The following cases are covered by this proposal and grouped due to the nature of the expected outcome. Note, that each sub-specification needs it's own implementations and tests.
+
+### (156A) Contracts without code
+The below is only usable between the blocks `CONSTANTINOPLE_FORK_BLKNUM` and `CONSTANTINOPLE_FORK_BLKNUM + EIP156_CLAIM_PERIOD` with `EIP156A_CLAIM_PERIOD = 2_000_000` blocks (aproximately one year).
+
+If the `v` value of a signature is (strictly) greater than `1024`, then calculate the sender as follows:
+
+- 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.
+- 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 standard 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.
+
+### (156B) Incorrectly computed addresses
+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 after `CONSTANTINOPLE_FORK_BLKNUM` by an amount equal to the total quantity of extant _future Ether_.
+
+### (156C) The self-destructed multi-signature library
+Extend the Solidity contract above (156B) by the following function:
+
+- `declareSuicidedDependency(sender,index)`: computes `rlp.encode([sender, index])`; then SHA3 of the code at that address. If the code equals the keccak of multi-signature library, add _future Ether_ to sender corresponding to the balance of that address.
+
+In addition to 156B, the hard fork would further increase the future Ether contract's balance after `CONSTANTINOPLE_FORK_BLKNUM` by an amount equal to the total quantity of extant _future Ether_ covered by 156C.
+
+### (156D) Map Cosmos addresses to Ethereum addresses
+Amend the Solidity contract above (156B) by the following function:
+
+- `declareCosmosAddress(pubkey)`: this checks that the `msg.sender` corresponds to the `pubkey`, calculates the corresponding Cosmos address, and allocates that number of _future Ether_ for `msg.sender`.
+
+## Rationale
+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.
+
+## Backwards Compatibility
+This proposal is not forward compatible and introduces backward incompatibilities in the set of valid transactions (156A) and a non-standard state-transition (156B,C,D).
+
+## Test Cases
+-156A: None.
+-156B,C,D: None.
+
+## Implementation
+-156A: None.
+-156B,C,D: None.
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).