From bb941f0b164898aa48556841ba6dcf9579cb8f24 Mon Sep 17 00:00:00 2001 From: 5chdn <5chdn@users.noreply.github.com> Date: Wed, 20 Dec 2017 11:47:43 +0100 Subject: [PATCH 1/3] Explore the option 156C --- EIPS/eip-156.md | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-156.md b/EIPS/eip-156.md index 70c78b4d7a4e10..a3b214c65c5a8d 100644 --- a/EIPS/eip-156.md +++ b/EIPS/eip-156.md @@ -12,7 +12,7 @@ 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 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). ## 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. @@ -44,19 +44,28 @@ Create a Solidity contract with the following functions: 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. + ## 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). +This proposal is not forward compatible and introduces backward incompatibilities in the set of valid transactions (156A) and a non-standard state-transition (156B, 156C). ## Test Cases -156A: None. -156B: None. +-156C: None. ## Implementation -156A: None. -156B: None. +-156C: None. ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 8ba0e7b8121f633f7a1f20ce88636ad22f99ef8c Mon Sep 17 00:00:00 2001 From: 5chdn <5chdn@users.noreply.github.com> Date: Wed, 20 Dec 2017 12:15:56 +0100 Subject: [PATCH 2/3] Honor @holiman as author of 156C and 156D --- EIPS/eip-156.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-156.md b/EIPS/eip-156.md index a3b214c65c5a8d..ee71468ef16394 100644 --- a/EIPS/eip-156.md +++ b/EIPS/eip-156.md @@ -2,7 +2,7 @@ EIP: 156 Title: Reclaiming of Ether in common classes of stuck accounts - Author: Vitalik Buterin, Afri Schoedon + Author: Vitalik Buterin, Martin Holst Swende, Afri Schoedon Type: Standard Track Category: Core Status: Draft From 092ac2d5786fc55220f963b048947529bbbfe4e7 Mon Sep 17 00:00:00 2001 From: 5chdn <5chdn@users.noreply.github.com> Date: Wed, 20 Dec 2017 12:28:48 +0100 Subject: [PATCH 3/3] Explore the option 156D --- EIPS/eip-156.md | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/EIPS/eip-156.md b/EIPS/eip-156.md index ee71468ef16394..c06b89037c734c 100644 --- a/EIPS/eip-156.md +++ b/EIPS/eip-156.md @@ -12,7 +12,7 @@ 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 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. @@ -51,21 +51,24 @@ Extend the Solidity contract above (156B) by the following function: 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, 156C). +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: None. --156C: None. +-156B,C,D: None. ## Implementation -156A: None. --156B: None. --156C: None. +-156B,C,D: None. ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).