Reclaiming of ether in common classes of stuck accounts posted by vbuterin 2016-has anything become of this?
andygilb opened this issue · 2 comments
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:
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:
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.
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) % 2160 == msg.sender; then checks that sha3(pubkey.encode('hex')) % 2160 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.
I created what I thought was a complete contract and funded it with some eth, only to find out later the contract had no functions or code, how do I get my eth out of this now (now classed as an EOW) Thanks.