Explore the option 156C

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
@@ -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). 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.
@@ -44,19 +44,31 @@ 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.
+
+### (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).
+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.
+-156B,C,D: None.
 
 ## Implementation
 -156A: None.
--156B: None.
+-156B,C,D: None.
 
 ## Copyright
 Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).