Migrating conversation from
opened 09:46AM - 14 Oct 16 UTC
closed 01:59AM - 24 Jan 22 UTC
stale
### 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.
2 Likes
Thank you for keeping this alive. I still support the return of ether stuck in the null address. How can we make this happen?
4 Likes
The best way to do this, IMO, is to review EIP-1 and try to resuscitate and modernize EIP-867 to work with the new EIP process. The first step is to submit a PR that changes the status to Draft and adds yourself as an author. If/when that’s merged, you can make changes as you see fit by submitting PRs that modify the EIP (they will be automerged), and once you’re happy you can request that it be moved to Review by submitting a PR that updates the status.
2 Likes