New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reclaiming of ether in common classes of stuck accounts #156

Open
vbuterin opened this Issue Oct 14, 2016 · 93 comments

Comments

Projects
None yet
@vbuterin
Collaborator

vbuterin commented Oct 14, 2016

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.

@jespow

This comment has been minimized.

Show comment
Hide comment
@jespow

jespow Oct 16, 2016

Speaking on behalf of Kraken, I would characterize this more as recompense than rescue. We did take on some not insignificant losses as a result of the mentioned bug in the old Ethereum javascript library. At the time, losses were covered out of Kraken's pocket to protect our clients. We would greatly appreciate the ability to recover the funds tied up in the incorrectly computed addresses. Thank you for this proposal.

jespow commented Oct 16, 2016

Speaking on behalf of Kraken, I would characterize this more as recompense than rescue. We did take on some not insignificant losses as a result of the mentioned bug in the old Ethereum javascript library. At the time, losses were covered out of Kraken's pocket to protect our clients. We would greatly appreciate the ability to recover the funds tied up in the incorrectly computed addresses. Thank you for this proposal.

@Smithgift

This comment has been minimized.

Show comment
Hide comment
@Smithgift

Smithgift Oct 16, 2016

Back when the DAO hardfork was debated, this category was brought up as a thing too difficult to fix therefore (INSERT CONCLUSION HERE). I'm glad we're considering fixing it now.

Smithgift commented Oct 16, 2016

Back when the DAO hardfork was debated, this category was brought up as a thing too difficult to fix therefore (INSERT CONCLUSION HERE). I'm glad we're considering fixing it now.

@cdetrio

This comment has been minimized.

Show comment
Hide comment
@cdetrio

cdetrio Dec 4, 2016

Member

@jespow @trapp If this spec were to be adopted so that Kraken's losses could be recompensed, would Kraken be willing to in turn cover the losses of users affected by the not safe enough ReplaySafeSplit contract?

Member

cdetrio commented Dec 4, 2016

@jespow @trapp If this spec were to be adopted so that Kraken's losses could be recompensed, would Kraken be willing to in turn cover the losses of users affected by the not safe enough ReplaySafeSplit contract?

@trapp

This comment has been minimized.

Show comment
Hide comment
@trapp

trapp Dec 4, 2016

@cdetrio I don't think we can compare the two issues with each other.

a.) The ethereumjs-lib did have a bug and did not work as intended.
b.) ReplaySafeSplit does not have a bug, it works according to the interface. It has two mandatory address parameters, you have to specify both when calling the contract. You cannot omit one.

When you specify 0x0 as target address then that is a user input error. When your GUI defaults to 0x0 when you leave one of the two empty, then that's an issue with the GUI. I'm not aware of any GUI that actually does this but see a similar issue in Mist: ethereum/mist#1128

The "fixed" version has an additional check for 0x0 as target address which helps with this specific case but still allows other nonsense addresses like 0x1, 0x2 etc. You cannot fix an issue like that on the contract level, the best place is the GUI (like address checksums).

c.) I also think it's offtopic here since the ReplaySafeSplit contract was not created or published by Kraken. The bug in this thread does not only affect Kraken, I would even say that the MyEtherWallet users lost a more due this bug compared to Kraken. Kraken just came forward in support for this initiative.

trapp commented Dec 4, 2016

@cdetrio I don't think we can compare the two issues with each other.

a.) The ethereumjs-lib did have a bug and did not work as intended.
b.) ReplaySafeSplit does not have a bug, it works according to the interface. It has two mandatory address parameters, you have to specify both when calling the contract. You cannot omit one.

When you specify 0x0 as target address then that is a user input error. When your GUI defaults to 0x0 when you leave one of the two empty, then that's an issue with the GUI. I'm not aware of any GUI that actually does this but see a similar issue in Mist: ethereum/mist#1128

The "fixed" version has an additional check for 0x0 as target address which helps with this specific case but still allows other nonsense addresses like 0x1, 0x2 etc. You cannot fix an issue like that on the contract level, the best place is the GUI (like address checksums).

c.) I also think it's offtopic here since the ReplaySafeSplit contract was not created or published by Kraken. The bug in this thread does not only affect Kraken, I would even say that the MyEtherWallet users lost a more due this bug compared to Kraken. Kraken just came forward in support for this initiative.

@neeeeeeext

This comment has been minimized.

Show comment
Hide comment

neeeeeeext commented Feb 1, 2017

@GriffGreen

This comment has been minimized.

Show comment
Hide comment
@GriffGreen

GriffGreen Mar 20, 2017

Maybe I'm missing it in the complexity... but if someone generates an account offline, for let's say a paper wallet, and then sends to it but claims it was an accident. What is to stop that person from doubling their ether if this EIP is implemented?

GriffGreen commented Mar 20, 2017

Maybe I'm missing it in the complexity... but if someone generates an account offline, for let's say a paper wallet, and then sends to it but claims it was an accident. What is to stop that person from doubling their ether if this EIP is implemented?

@GriffGreen

This comment has been minimized.

Show comment
Hide comment
@GriffGreen

GriffGreen Mar 20, 2017

@LefterisJP and @jbaylina figured it out for me!

http://ethereum.stackexchange.com/questions/760/how-is-the-address-of-an-ethereum-contract-computed#761

The contract address is deterministically computed from the address that created it :-), so the paper wallet trick wouldn't work.

GriffGreen commented Mar 20, 2017

@LefterisJP and @jbaylina figured it out for me!

http://ethereum.stackexchange.com/questions/760/how-is-the-address-of-an-ethereum-contract-computed#761

The contract address is deterministically computed from the address that created it :-), so the paper wallet trick wouldn't work.

@axelay

This comment has been minimized.

Show comment
Hide comment
@axelay

axelay Jun 5, 2017

Posting on behalf of QuadrigaCX, we would like to see an amendment to this proposal in order to reclaim trapped Ether on contracts that have no ability to send.

Not only to rescue some past mistakes but also thinking about providing a safety net for the future. Even though progresses have been made in Solidity to ensure return of the funds, there could still be a chance of Ether becoming trapped.

axelay commented Jun 5, 2017

Posting on behalf of QuadrigaCX, we would like to see an amendment to this proposal in order to reclaim trapped Ether on contracts that have no ability to send.

Not only to rescue some past mistakes but also thinking about providing a safety net for the future. Even though progresses have been made in Solidity to ensure return of the funds, there could still be a chance of Ether becoming trapped.

@Souptacular

This comment has been minimized.

Show comment
Hide comment
@Souptacular

Souptacular Jun 6, 2017

Member

Hi @axelay,

there could still be a chance of Ether becoming trapped

What are the other ways ether can become trapped? Are you meaning functions that are payable, but do not have a means to get the ether out of the function?

Also, please reach out to me at hudson@ethereum.org [PGP 028D 1459 247B 9596 if you prefer] so I can verify that you are representing QuadrigaCX officially. There have recently been people in the community that seem to be speaking for QuadrigaCX, but are not actually employed or represent QuadrigaCX in any way.

Edit: Confirmed that @axelay is representing QuadrigaCX.

Thanks!

Member

Souptacular commented Jun 6, 2017

Hi @axelay,

there could still be a chance of Ether becoming trapped

What are the other ways ether can become trapped? Are you meaning functions that are payable, but do not have a means to get the ether out of the function?

Also, please reach out to me at hudson@ethereum.org [PGP 028D 1459 247B 9596 if you prefer] so I can verify that you are representing QuadrigaCX officially. There have recently been people in the community that seem to be speaking for QuadrigaCX, but are not actually employed or represent QuadrigaCX in any way.

Edit: Confirmed that @axelay is representing QuadrigaCX.

Thanks!

@mjmau

This comment has been minimized.

Show comment
Hide comment
@mjmau

mjmau Jun 8, 2017

I created a tool to scan for the "ether stuck in empty contract" case. It finds about 3500 ETH in almost 300 empty contracts. I'm not sure I understand the edge cases and welcome any review.

https://gist.github.com/mjmau/e073091446751b08762c8c65ae13a37d

mjmau commented Jun 8, 2017

I created a tool to scan for the "ether stuck in empty contract" case. It finds about 3500 ETH in almost 300 empty contracts. I'm not sure I understand the edge cases and welcome any review.

https://gist.github.com/mjmau/e073091446751b08762c8c65ae13a37d

@netpro2k

This comment has been minimized.

Show comment
Hide comment
@netpro2k

netpro2k Jun 8, 2017

we would like to see an amendment to this proposal in order to reclaim trapped Ether on contracts that have no ability to send.

Wouldn't this be problematic for contracts that are intentionally "burning" ether by locking it up? Sure this could be done in the future in other ways (sending to a dead address) but I would be surprised if there didn't already exist contracts for which this would be an issue.

netpro2k commented Jun 8, 2017

we would like to see an amendment to this proposal in order to reclaim trapped Ether on contracts that have no ability to send.

Wouldn't this be problematic for contracts that are intentionally "burning" ether by locking it up? Sure this could be done in the future in other ways (sending to a dead address) but I would be surprised if there didn't already exist contracts for which this would be an issue.

@holiman

This comment has been minimized.

Show comment
Hide comment
@holiman

holiman Jun 8, 2017

Contributor

Wouldn't this be problematic for contracts that are intentionally "burning" ether by locking it up? Sure this could be done in the future in other ways (sending to a dead address) but I would be surprised if there didn't already exist contracts for which this would be an issue.

Intentional burns are usually sending to 0x or some 0xdead address. Intentionally locking the ether up in a 'dead' contract to which there is actually a key seems very unlikely.

Contributor

holiman commented Jun 8, 2017

Wouldn't this be problematic for contracts that are intentionally "burning" ether by locking it up? Sure this could be done in the future in other ways (sending to a dead address) but I would be surprised if there didn't already exist contracts for which this would be an issue.

Intentional burns are usually sending to 0x or some 0xdead address. Intentionally locking the ether up in a 'dead' contract to which there is actually a key seems very unlikely.

@Arachnid

This comment has been minimized.

Show comment
Hide comment
@Arachnid

Arachnid Jun 8, 2017

Collaborator

Posting on behalf of QuadrigaCX, we would like to see an amendment to this proposal in order to reclaim trapped Ether on contracts that have no ability to send.

Do you have a technical proposal on how that could be achieved?

Devising a fair rule for this seems particularly problematic, since QuadrigaCX didn't even deploy the contract in question.

Collaborator

Arachnid commented Jun 8, 2017

Posting on behalf of QuadrigaCX, we would like to see an amendment to this proposal in order to reclaim trapped Ether on contracts that have no ability to send.

Do you have a technical proposal on how that could be achieved?

Devising a fair rule for this seems particularly problematic, since QuadrigaCX didn't even deploy the contract in question.

@holiman

This comment has been minimized.

Show comment
Hide comment
@holiman

holiman Jun 8, 2017

Contributor

From a technical perspective, I'd like to point out some things.

  • It's technically possible to (on-chain) verify that a contract c only ever can send the CALLVALUE.
  • It's technically possible to (on-chain) verify that such a contract holds balance.
  • Thus, it could be determined that the balance is trapped.

Now, the hard part would be whom to ascribe the tokens. Because it's impossible on-chain to see who sent what when and if that got stuck. So the only thing that could be done would be to let the account who deployed the contract get the credits.

I don't see how it could be done in any other way, from a technical perspective.

Contributor

holiman commented Jun 8, 2017

From a technical perspective, I'd like to point out some things.

  • It's technically possible to (on-chain) verify that a contract c only ever can send the CALLVALUE.
  • It's technically possible to (on-chain) verify that such a contract holds balance.
  • Thus, it could be determined that the balance is trapped.

Now, the hard part would be whom to ascribe the tokens. Because it's impossible on-chain to see who sent what when and if that got stuck. So the only thing that could be done would be to let the account who deployed the contract get the credits.

I don't see how it could be done in any other way, from a technical perspective.

@winsvega

This comment has been minimized.

Show comment
Hide comment
@winsvega

winsvega Jun 16, 2017

Contributor

It looks more like a client's problem not a protocol issue. If you add a way to send ether back that could potentially compromise the whole system and lead to some weird scenarios that we don't see at the moment.

The scheme like
key -> sign transaction -> send
is pretty simple.

But the scheme like
if v> ... and signature is like this then if ... then make the transaction as if it was if ...
is not simple and it could break the whole concept IMHO

The warnings to the user should be done on a client side in a form like:
"Are you sure that you want to send this transaction to that contract. This would result in ... "

Contributor

winsvega commented Jun 16, 2017

It looks more like a client's problem not a protocol issue. If you add a way to send ether back that could potentially compromise the whole system and lead to some weird scenarios that we don't see at the moment.

The scheme like
key -> sign transaction -> send
is pretty simple.

But the scheme like
if v> ... and signature is like this then if ... then make the transaction as if it was if ...
is not simple and it could break the whole concept IMHO

The warnings to the user should be done on a client side in a form like:
"Are you sure that you want to send this transaction to that contract. This would result in ... "

@FlaxFlax

This comment has been minimized.

Show comment
Hide comment
@FlaxFlax

FlaxFlax Jun 24, 2017

Just want to say that I'm one the the noobs that where lucky enough to sent ether with an empty "TO". I know, I know :(

Now all is stuck in this useless empty contract. I blieve that this will happen again and again. In my case it was a bug but it's quite easy to fall for the believe that it is safe to test send to an empty address as it would fail and bounce the transaction.

Anyhow, any means to reclaim it would be deeply appreciated!

FlaxFlax commented Jun 24, 2017

Just want to say that I'm one the the noobs that where lucky enough to sent ether with an empty "TO". I know, I know :(

Now all is stuck in this useless empty contract. I blieve that this will happen again and again. In my case it was a bug but it's quite easy to fall for the believe that it is safe to test send to an empty address as it would fail and bounce the transaction.

Anyhow, any means to reclaim it would be deeply appreciated!

@sardoru

This comment has been minimized.

Show comment
Hide comment
@sardoru

sardoru Jul 9, 2017

Hi All, I share same situation with @FlaxFlax. Accidentally sent to blank To: field... it was 100 Ether .... :(

Tx: https://etherscan.io/tx/0x761215d5ecb2162dc865960a7e4ce9c2189c9bd4a76de6caba80e626b60716ba

sardoru commented Jul 9, 2017

Hi All, I share same situation with @FlaxFlax. Accidentally sent to blank To: field... it was 100 Ether .... :(

Tx: https://etherscan.io/tx/0x761215d5ecb2162dc865960a7e4ce9c2189c9bd4a76de6caba80e626b60716ba

@ryancharleston

This comment has been minimized.

Show comment
Hide comment
@ryancharleston

ryancharleston Aug 1, 2017

If/when this feature gets implemented into Ethereum, could it be made to apply to all past transaction or can it only be made to apply to future transactions?

ryancharleston commented Aug 1, 2017

If/when this feature gets implemented into Ethereum, could it be made to apply to all past transaction or can it only be made to apply to future transactions?

@timkae

This comment has been minimized.

Show comment
Hide comment
@timkae

timkae Aug 6, 2017

Is this something that could be used to help me recover ETH sent to an invalid address?

My story here: https://www.reddit.com/r/ethereum/comments/6rsvak/sent_3_eth_to_an_address_with_typo/?utm_content=title&utm_medium=user&utm_source=reddit

timkae commented Aug 6, 2017

Is this something that could be used to help me recover ETH sent to an invalid address?

My story here: https://www.reddit.com/r/ethereum/comments/6rsvak/sent_3_eth_to_an_address_with_typo/?utm_content=title&utm_medium=user&utm_source=reddit

@Smithgift

This comment has been minimized.

Show comment
Hide comment
@Smithgift

Smithgift Aug 6, 2017

@timkae: Unfortunately not. There's no simple way to know if sending to an address was intended or a typo, just from the addresses themselves.

Smithgift commented Aug 6, 2017

@timkae: Unfortunately not. There's no simple way to know if sending to an address was intended or a typo, just from the addresses themselves.

@tjayrush

This comment has been minimized.

Show comment
Hide comment
@tjayrush

tjayrush Aug 16, 2017

Has there been any discussion about the following aspect of this original proposal? Quoting from initial post:

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"

Most of the comments here are from people who obviously agree with the proposal because they lost ETH. Are there any downsides to this proposal? Certainly it gives ammunition to people who argue that ETH is less immutable than it should be. I am not taking a side, but I think the political aspects of the proposal should be discussed.

tjayrush commented Aug 16, 2017

Has there been any discussion about the following aspect of this original proposal? Quoting from initial post:

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"

Most of the comments here are from people who obviously agree with the proposal because they lost ETH. Are there any downsides to this proposal? Certainly it gives ammunition to people who argue that ETH is less immutable than it should be. I am not taking a side, but I think the political aspects of the proposal should be discussed.

@holiman

This comment has been minimized.

Show comment
Hide comment
@holiman

holiman Aug 16, 2017

Contributor

@tjayrush My view on that is that the EIP should concern the technical implementation, so that the technical proposal is finished and fleshed out. Once that is done, and a concrete detailed proposal is available, that proposal should be discussed in a broader scope, which includes the larger community.

So step 1: concrete technical spec, step 2: determine if it's supported by community.

...just my 5 cents.

Contributor

holiman commented Aug 16, 2017

@tjayrush My view on that is that the EIP should concern the technical implementation, so that the technical proposal is finished and fleshed out. Once that is done, and a concrete detailed proposal is available, that proposal should be discussed in a broader scope, which includes the larger community.

So step 1: concrete technical spec, step 2: determine if it's supported by community.

...just my 5 cents.

@MicahZoltu

This comment has been minimized.

Show comment
Hide comment
@MicahZoltu

MicahZoltu Aug 16, 2017

Contributor

@tjayrush This proposal adds code, and therefore VM complexity, technical debt, etc. and only helps out people who have lost something. In general, I think anything that requires adding code to all nodes (e.g., part of consensus) needs to have a very strong argument for it. While I can appreciate the desire to get back lost money, I'm not convinced the total value restored to the userbase outweighs the total cost to the ecosystem. Do we have any idea exactly how much money would be recoverable with this? Do we have any idea the level of technical complexity required to implement (and maintain forever) the code associated with this change?

Contributor

MicahZoltu commented Aug 16, 2017

@tjayrush This proposal adds code, and therefore VM complexity, technical debt, etc. and only helps out people who have lost something. In general, I think anything that requires adding code to all nodes (e.g., part of consensus) needs to have a very strong argument for it. While I can appreciate the desire to get back lost money, I'm not convinced the total value restored to the userbase outweighs the total cost to the ecosystem. Do we have any idea exactly how much money would be recoverable with this? Do we have any idea the level of technical complexity required to implement (and maintain forever) the code associated with this change?

@mjmau

This comment has been minimized.

Show comment
Hide comment
@mjmau

mjmau Aug 16, 2017

@MicahZoltu With regard to your question of how much money, the answer has two parts: how much has already been lost, and how much will be lost in the future. I tried to estimate how much has been lost already to the subset of "sent to new contract with null code" in my previous comment above, which found around 3500 ETH in that category.

See the gist https://gist.github.com/mjmau/e073091446751b08762c8c65ae13a37d

mjmau commented Aug 16, 2017

@MicahZoltu With regard to your question of how much money, the answer has two parts: how much has already been lost, and how much will be lost in the future. I tried to estimate how much has been lost already to the subset of "sent to new contract with null code" in my previous comment above, which found around 3500 ETH in that category.

See the gist https://gist.github.com/mjmau/e073091446751b08762c8c65ae13a37d

@ryancharleston

This comment has been minimized.

Show comment
Hide comment
@ryancharleston

ryancharleston Aug 16, 2017

A recent ICO (REXmls) has 6687 ETH (~$2 million) sitting in an address an address that doesn't actually exist (seen here > https://etherscan.io/address/0x03e4b00b607d0980668ca6e50201576b00000000), due to a misspelled address in their original ICO smart contract. This is a project that would definitely benefit from recovering funds and in doing so would benefit Ethereum and the Ethereum ecosystem as a whole.

ryancharleston commented Aug 16, 2017

A recent ICO (REXmls) has 6687 ETH (~$2 million) sitting in an address an address that doesn't actually exist (seen here > https://etherscan.io/address/0x03e4b00b607d0980668ca6e50201576b00000000), due to a misspelled address in their original ICO smart contract. This is a project that would definitely benefit from recovering funds and in doing so would benefit Ethereum and the Ethereum ecosystem as a whole.

@MicahZoltu

This comment has been minimized.

Show comment
Hide comment
@MicahZoltu

MicahZoltu Aug 17, 2017

Contributor

@GriffGreen Can you explain how you came to the conclusion that the paper wallet trick won't work? I also must be missing something, but unfortunately the SE answer you linked wasn't new information to me and even knowing that it still seems like the paper wallet trick would work.

  1. Account A create's wallet contract offline.
  2. Account B sends funds to wallet.
  3. Wait for hardfork.
  4. Account B receives refund ETH.
  5. Account A uploads wallet contract.
  6. Account A withdraws original ETH.
Contributor

MicahZoltu commented Aug 17, 2017

@GriffGreen Can you explain how you came to the conclusion that the paper wallet trick won't work? I also must be missing something, but unfortunately the SE answer you linked wasn't new information to me and even knowing that it still seems like the paper wallet trick would work.

  1. Account A create's wallet contract offline.
  2. Account B sends funds to wallet.
  3. Wait for hardfork.
  4. Account B receives refund ETH.
  5. Account A uploads wallet contract.
  6. Account A withdraws original ETH.
@plutoegg

This comment has been minimized.

Show comment
Hide comment
@plutoegg

plutoegg Nov 7, 2017

There are several different suggestions in this thread and elsewhere relating to also including recovery of any funds accidentally sent to the 0x00 address .
Since this is a relatively common source of "lost" funds, if these were to be included it could be a special case for the 0x00 address, and would need to be applied regardless of whether the cause was:

  1. User error leaving to address completely blank, and therefore sending to 0x00.
  2. The early bug, later fixed, with leading whitespaces in the to string i.e. to: " 0x19df848c..." went instead to 0x00 (https://www.reddit.com/r/ethereum/comments/3gwczr/be_careful_it_is_so_easy_to_make_a_mistake_and/)

The confusion comes that the 0x00 may have been used in the past as a purposeful "burn" address. Therefore any transfers to 0x00 from contracts should be treated as having been purposeful attempts to burn ether and be untouched. There is no case where an externally owned account would likely have purposely sent a transfer to 0x00, and so transfers from these could be treated as "recoverable".

plutoegg commented Nov 7, 2017

There are several different suggestions in this thread and elsewhere relating to also including recovery of any funds accidentally sent to the 0x00 address .
Since this is a relatively common source of "lost" funds, if these were to be included it could be a special case for the 0x00 address, and would need to be applied regardless of whether the cause was:

  1. User error leaving to address completely blank, and therefore sending to 0x00.
  2. The early bug, later fixed, with leading whitespaces in the to string i.e. to: " 0x19df848c..." went instead to 0x00 (https://www.reddit.com/r/ethereum/comments/3gwczr/be_careful_it_is_so_easy_to_make_a_mistake_and/)

The confusion comes that the 0x00 may have been used in the past as a purposeful "burn" address. Therefore any transfers to 0x00 from contracts should be treated as having been purposeful attempts to burn ether and be untouched. There is no case where an externally owned account would likely have purposely sent a transfer to 0x00, and so transfers from these could be treated as "recoverable".

@tinybike

This comment has been minimized.

Show comment
Hide comment
@tinybike

tinybike Nov 7, 2017

Member

@GriffGreen I would also like to know why the paper wallet trick won't work; @MicahZoltu's sequence of events looks correct to me.

I share @MicahZoltu's concerns re: complexity risks of this EIP. Can anyone comment on how much extra code / complexity would be needed to implement this? My gut feeling is that unless it's very simple, the risk associated with implementation outweighs the benefits of reclaiming lost funds.

Member

tinybike commented Nov 7, 2017

@GriffGreen I would also like to know why the paper wallet trick won't work; @MicahZoltu's sequence of events looks correct to me.

I share @MicahZoltu's concerns re: complexity risks of this EIP. Can anyone comment on how much extra code / complexity would be needed to implement this? My gut feeling is that unless it's very simple, the risk associated with implementation outweighs the benefits of reclaiming lost funds.

@k26dr

This comment has been minimized.

Show comment
Hide comment
@k26dr

k26dr Nov 7, 2017

Is this being considered as a solution to the bricked Parity multisig wallets?

k26dr commented Nov 7, 2017

Is this being considered as a solution to the bricked Parity multisig wallets?

@greggdourgarian

This comment has been minimized.

Show comment
Hide comment
@greggdourgarian

greggdourgarian Nov 7, 2017

Can we please be upright and magnanimous and talk straight about what Ethereum is? Is it immutable and uncensorable as Ethereum.org suggests? Obviously not, and I'm okay with that given our youthfulness.

Sadly, pull requests to correct to correct it get rejected by Foundation memebers overcome with shame about the DAO hardfork (ethereum/ethereum-org#617 (comment)).

Myself, I can't stay in a community that doesn't act ethically. If you want to keep on hard forking to recover funds for people, I really don't care. But let's at least say what we do and do what we say.

greggdourgarian commented Nov 7, 2017

Can we please be upright and magnanimous and talk straight about what Ethereum is? Is it immutable and uncensorable as Ethereum.org suggests? Obviously not, and I'm okay with that given our youthfulness.

Sadly, pull requests to correct to correct it get rejected by Foundation memebers overcome with shame about the DAO hardfork (ethereum/ethereum-org#617 (comment)).

Myself, I can't stay in a community that doesn't act ethically. If you want to keep on hard forking to recover funds for people, I really don't care. But let's at least say what we do and do what we say.

@tinybike

This comment has been minimized.

Show comment
Hide comment
@tinybike

tinybike Nov 7, 2017

Member

@greggdourgarian while I think your point is worth discussing, IMO this EIP is the wrong place for that discussion.

Member

tinybike commented Nov 7, 2017

@greggdourgarian while I think your point is worth discussing, IMO this EIP is the wrong place for that discussion.

@greggdourgarian

This comment has been minimized.

Show comment
Hide comment
@greggdourgarian

greggdourgarian Nov 7, 2017

@tinybike Thanks for responding. I like this EIP and believe it technically excellent.

Nevertheless, it crosses the barrier of mere technical improvement and risks defining our ethical framework or lack thereof.

Given its importance, let's use this opportunity to lift up both Ethereum and the wider community's understanding of blockchain governance.

greggdourgarian commented Nov 7, 2017

@tinybike Thanks for responding. I like this EIP and believe it technically excellent.

Nevertheless, it crosses the barrier of mere technical improvement and risks defining our ethical framework or lack thereof.

Given its importance, let's use this opportunity to lift up both Ethereum and the wider community's understanding of blockchain governance.

@Montoya

This comment has been minimized.

Show comment
Hide comment
@Montoya

Montoya Nov 7, 2017

This seems to me like a technical improvement and a surgical fix to an existing problem. Nothing about this resembles a "hardfork." Naysayers will criticize ETH regardless of what is done, but I would not let their opinions dictate the outcome.

Full disclosure: I have no ether in any locked accounts.

Montoya commented Nov 7, 2017

This seems to me like a technical improvement and a surgical fix to an existing problem. Nothing about this resembles a "hardfork." Naysayers will criticize ETH regardless of what is done, but I would not let their opinions dictate the outcome.

Full disclosure: I have no ether in any locked accounts.

@Arachnid

This comment has been minimized.

Show comment
Hide comment
@Arachnid

Arachnid Nov 7, 2017

Collaborator

@Montoya A hard fork is any change to the rules of the chain that requires an update for clients to validate it. This EIP would require a hard fork.

Collaborator

Arachnid commented Nov 7, 2017

@Montoya A hard fork is any change to the rules of the chain that requires an update for clients to validate it. This EIP would require a hard fork.

@greggdourgarian

This comment has been minimized.

Show comment
Hide comment
@greggdourgarian

greggdourgarian Nov 7, 2017

@Montoya You're right - we'll never please everyone. But we will win over many ideological opponents by articulating and acting on a consistent, ethical framework. This EIP does represent a hard fork as someone else pointed out, but given the youthfulness of the project, there is nothing inherently wrong with that.

greggdourgarian commented Nov 7, 2017

@Montoya You're right - we'll never please everyone. But we will win over many ideological opponents by articulating and acting on a consistent, ethical framework. This EIP does represent a hard fork as someone else pointed out, but given the youthfulness of the project, there is nothing inherently wrong with that.

@supRNurse

This comment has been minimized.

Show comment
Hide comment
@supRNurse

supRNurse Nov 8, 2017

On July 28th 2016 I tried to use the "safereplaysplitter" contact Vitalik Buterin blogged about in his post "Onward from the hard-fork". It was among my first attempts at using smart contracts and I was very excited. I sent a small amount through per instructions and it worked perfectly. I then sent my entire account through. 1493 Ether never arrived in my account. Instead they were sent by default to 0x0000000000000000000000000000000000000000. Evidently if the drop down menu for the receiving account is deselected or left blank the ether travels by default to the zero address. My Ether is still there stranded in that un-spendable account. Its loss even at July 2016 prices was devastating. Most people expressed sympathy and they tried to explain "decentralization" without sounding cold. I hold out hope that you developers will find a solution to fix obvious mistakes that doesn't require hard forks. I am so terribly sorry when I hear of good people losing Ether due to unforeseen mistakes. Please guys you are changing the world with Etherium you are our generation's best and brightest please find a solution!
Best
Kevin

supRNurse commented Nov 8, 2017

On July 28th 2016 I tried to use the "safereplaysplitter" contact Vitalik Buterin blogged about in his post "Onward from the hard-fork". It was among my first attempts at using smart contracts and I was very excited. I sent a small amount through per instructions and it worked perfectly. I then sent my entire account through. 1493 Ether never arrived in my account. Instead they were sent by default to 0x0000000000000000000000000000000000000000. Evidently if the drop down menu for the receiving account is deselected or left blank the ether travels by default to the zero address. My Ether is still there stranded in that un-spendable account. Its loss even at July 2016 prices was devastating. Most people expressed sympathy and they tried to explain "decentralization" without sounding cold. I hold out hope that you developers will find a solution to fix obvious mistakes that doesn't require hard forks. I am so terribly sorry when I hear of good people losing Ether due to unforeseen mistakes. Please guys you are changing the world with Etherium you are our generation's best and brightest please find a solution!
Best
Kevin

@sciyoshi

This comment has been minimized.

Show comment
Hide comment
@sciyoshi

sciyoshi Nov 8, 2017

As noted elsewhere, this EIP as written won't allow withdrawing ether from multisig contracts created using the recently suicided Parity wallet library, since they do have code at their address. The class of frozen funds this proposal would allow spending is only those sent to empty/nonexistent contracts, and should be fairly uncontroversial since it gives no preference to user or application.

sciyoshi commented Nov 8, 2017

As noted elsewhere, this EIP as written won't allow withdrawing ether from multisig contracts created using the recently suicided Parity wallet library, since they do have code at their address. The class of frozen funds this proposal would allow spending is only those sent to empty/nonexistent contracts, and should be fairly uncontroversial since it gives no preference to user or application.

@holiman

This comment has been minimized.

Show comment
Hide comment
@holiman

holiman Nov 8, 2017

Contributor

Here's my attempt at a technical implementation for amending the eip:

Create a solidity contract with the following function

  • declareSuicidedDependency(sender,index): computes rlp.encode([sender, index]); then sha3 of the code at that address. If the code equals <keccak of parity-wallet>, add futureTokens to sender corresponding to the balance of address.

Note1: Since the address to delegatecall was marked constant, it's compiled into the bytescode as a PUSH20 0x863df6bfa4469f3ead0be8f9f2aae51c91a907b4. Had it ben implemented as a dynamic delegatecall operating with storage-variable, this would not have been possible.

Note2: It is still possible to deposit ether to the contracts, so the declareSuicidedDependency should always fully overwrite the futureTokens balance with the current balance.

Note3: This solution would not be able to recover tokens.

Note4: I'm just exploring the technical possibilities here, not championing any particular path forward.

Contributor

holiman commented Nov 8, 2017

Here's my attempt at a technical implementation for amending the eip:

Create a solidity contract with the following function

  • declareSuicidedDependency(sender,index): computes rlp.encode([sender, index]); then sha3 of the code at that address. If the code equals <keccak of parity-wallet>, add futureTokens to sender corresponding to the balance of address.

Note1: Since the address to delegatecall was marked constant, it's compiled into the bytescode as a PUSH20 0x863df6bfa4469f3ead0be8f9f2aae51c91a907b4. Had it ben implemented as a dynamic delegatecall operating with storage-variable, this would not have been possible.

Note2: It is still possible to deposit ether to the contracts, so the declareSuicidedDependency should always fully overwrite the futureTokens balance with the current balance.

Note3: This solution would not be able to recover tokens.

Note4: I'm just exploring the technical possibilities here, not championing any particular path forward.

@ebuchman

This comment has been minimized.

Show comment
Hide comment
@ebuchman

ebuchman Nov 15, 2017

It would not be possible to go from ethereum address to cosmos address, but it would be possible to go from ethereum public key to cosmos address, since they both use the secp256k1 pubkey. Since we can show that the address in question is the ripemd160(sha256(secp256k1_pubkey)), we can be confident no one has a corresponding private key that could actually unlock it.

ebuchman commented Nov 15, 2017

It would not be possible to go from ethereum address to cosmos address, but it would be possible to go from ethereum public key to cosmos address, since they both use the secp256k1 pubkey. Since we can show that the address in question is the ripemd160(sha256(secp256k1_pubkey)), we can be confident no one has a corresponding private key that could actually unlock it.

@holiman

This comment has been minimized.

Show comment
Hide comment
@holiman

holiman Nov 15, 2017

Contributor

Sorry, why not? We have the last 20 bytes of keccak (pubkey) in eth address, no?

Contributor

holiman commented Nov 15, 2017

Sorry, why not? We have the last 20 bytes of keccak (pubkey) in eth address, no?

@ebuchman

This comment has been minimized.

Show comment
Hide comment
@ebuchman

ebuchman Nov 15, 2017

Yes, that's right, but we'd have to get the pubkey itself into the EVM. To be clear, the problem is as follows:

  • We have privkey and pubkey
  • There are funds in account with lockedAddress = ripemd160(sha2(pubkey)). These funds are unspendable since there is obviously no known privkey2 such that lockedAddress = keccak(privkey2.pubkey)[12:]
  • We could send a transaction from account keccak(pubkey)[12:]
  • If a contract can get access to the pubkey of the msg.sender, then we could imagine an EIP156 contract could check that ripemd160(sha2(msg.sender.pubkey) = lockedAddress and thereby redeem the locked funds to the msg.sender. That would be a problem solved!
  • AFAIK, getting the pubkey of the sender was not possibl, but perhaps it is now possible in Byzantium if we pass in signature bytes in the transaction data ?

Thanks.

ebuchman commented Nov 15, 2017

Yes, that's right, but we'd have to get the pubkey itself into the EVM. To be clear, the problem is as follows:

  • We have privkey and pubkey
  • There are funds in account with lockedAddress = ripemd160(sha2(pubkey)). These funds are unspendable since there is obviously no known privkey2 such that lockedAddress = keccak(privkey2.pubkey)[12:]
  • We could send a transaction from account keccak(pubkey)[12:]
  • If a contract can get access to the pubkey of the msg.sender, then we could imagine an EIP156 contract could check that ripemd160(sha2(msg.sender.pubkey) = lockedAddress and thereby redeem the locked funds to the msg.sender. That would be a problem solved!
  • AFAIK, getting the pubkey of the sender was not possibl, but perhaps it is now possible in Byzantium if we pass in signature bytes in the transaction data ?

Thanks.

@shawnholt

This comment has been minimized.

Show comment
Hide comment
@shawnholt

shawnholt Nov 15, 2017

@jaekwon and others are bringing some variation of use cases. The EIP refers to a "Stuck Account". Would be helpful if @vbuterin could make the definition of stuck account a bit more crisp.

** IMO we should be very careful that this is not in any way a reversal of a valid transaction (ie. DAO use case.) **

Currently lists:

  • 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.

shawnholt commented Nov 15, 2017

@jaekwon and others are bringing some variation of use cases. The EIP refers to a "Stuck Account". Would be helpful if @vbuterin could make the definition of stuck account a bit more crisp.

** IMO we should be very careful that this is not in any way a reversal of a valid transaction (ie. DAO use case.) **

Currently lists:

  • 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.
@matrixator

This comment has been minimized.

Show comment
Hide comment
@matrixator

matrixator Nov 15, 2017

It's a reversal of state of the network, however you look at it, but at this early stage it's OK...as kong as we fix ALL problems caused by Parity's numerous bugs.
If we decide it's not worth the pain, because we fear that BTC maximalists will laugh because ETH is just an Excel sheet, then leave it as it is.
I hope the community has the guts, the strength and sef confidence to do what is right.

matrixator commented Nov 15, 2017

It's a reversal of state of the network, however you look at it, but at this early stage it's OK...as kong as we fix ALL problems caused by Parity's numerous bugs.
If we decide it's not worth the pain, because we fear that BTC maximalists will laugh because ETH is just an Excel sheet, then leave it as it is.
I hope the community has the guts, the strength and sef confidence to do what is right.

@Montoya

This comment has been minimized.

Show comment
Hide comment
@Montoya

Montoya Nov 15, 2017

If we decide it's not worth the pain, because we fear that BTC maximalists will laugh because ETH is just an Excel sheet, then leave it as it is.

They have felt this way for a long time, and yet the value of ETH continues to go up. I wouldn't base the decision here on what a clearly biased, defensive group of "competitors" thinks.

Montoya commented Nov 15, 2017

If we decide it's not worth the pain, because we fear that BTC maximalists will laugh because ETH is just an Excel sheet, then leave it as it is.

They have felt this way for a long time, and yet the value of ETH continues to go up. I wouldn't base the decision here on what a clearly biased, defensive group of "competitors" thinks.

@shawnholt

This comment has been minimized.

Show comment
Hide comment
@shawnholt

shawnholt Nov 15, 2017

This is a good article on immutability - you can skim it as its a long read.

The point I want to reiterate is that we never rollback a valid transaction (even for theft.) Creating a function to recover stuck ETH IMO is totally different and reasonable. As I mentioned though, with great power comes great responsibility, so I recommend considering a cost and approval process for this scenario. Economic incentives and oversight should help mitigate malicious, yet unforeseen hacking vectors - at some point the vote could be removed but having a cost could discourage bad coding.

I hope the DAO was the first and last transaction rollback and we can support this EIP without undermining confidence in Ethereum.

shawnholt commented Nov 15, 2017

This is a good article on immutability - you can skim it as its a long read.

The point I want to reiterate is that we never rollback a valid transaction (even for theft.) Creating a function to recover stuck ETH IMO is totally different and reasonable. As I mentioned though, with great power comes great responsibility, so I recommend considering a cost and approval process for this scenario. Economic incentives and oversight should help mitigate malicious, yet unforeseen hacking vectors - at some point the vote could be removed but having a cost could discourage bad coding.

I hope the DAO was the first and last transaction rollback and we can support this EIP without undermining confidence in Ethereum.

@Arachnid

This comment has been minimized.

Show comment
Hide comment
@Arachnid

Arachnid Nov 15, 2017

Collaborator

I hope the DAO was the first and last transaction rollback and we can support this EIP without undermining confidence in Ethereum.

The DAO was not a transaction rollback. Please let's a) try and focus on the topic here, and b) Use correct terminology.

Collaborator

Arachnid commented Nov 15, 2017

I hope the DAO was the first and last transaction rollback and we can support this EIP without undermining confidence in Ethereum.

The DAO was not a transaction rollback. Please let's a) try and focus on the topic here, and b) Use correct terminology.

@holiman

This comment has been minimized.

Show comment
Hide comment
@holiman

holiman Nov 16, 2017

Contributor

@jaekwon @ebuchman Seems to be more complicated than I thought initally. From the seed phrase pasted above:

Private key, derived on path 44'/118'/0'/0/0:
	0x499c7dce161a8db03bfaa3a1035156250d932ac917b66e9c08c60b07a20a9dae
COS Public Key               : 0x02D7485091B95C158EEEC8ED2E248F7164BE5DF0956583DB3BB99F326390081CF8
COS Public Key (uncompressed): 0x04D7485091B95C158EEEC8ED2E248F7164BE5DF0956583DB3BB99F326390081CF8F334FDF8ACC7E22C69FDDEDD4FD46DBDDA4F6E635D6F5386350E079101FE5EA8
Eth public key               : 0x04D7485091B95C158EEEC8ED2E248F7164BE5DF0956583DB3BB99F326390081CF8F334FDF8ACC7E22C69FDDEDD4FD46DBDDA4F6E635D6F5386350E079101FE5EA8
Keccak256(pubBytes[1:]) 0xE2DE2CFE745900E94311C55B01E485D6B15E85764B1BE37FA71F2D57AF26B459
Keccak256(pubBytes[1:])[12:] 0x01E485D6B15E85764B1BE37FA71F2D57AF26B459
Public eth: 0x01E485D6B15E85764B1BE37FA71F2D57AF26B459
Cos Address: 0x4FB8FAB66EF33955F10D59B9B86183148858DBCE
Sha256(Cosmos Public Key): 0x88E01006EA89D0400A9FCC7224291FC7A231DEE00A03386A62AE8F4717E16CA7
Kec256(Cosmos Public Key): 0xF0F76DE539979DD340B5DD79F3E28A614F153D77F335245C7FA80DD143AEF7FE
Ripe160(Sha256(Cosmos Public Key)): 0x4FB8FAB66EF33955F10D59B9B86183148858DBCE
  • Cosmos appear to use compressed public keys, whereas ETH does not.
  • Eth ignores the first byte of the public key, whereas cosmos uses all.

So it's not just a matter of "add the missing 12 bytes of the sha3-hash and then do ripemd". I think e.g. a sha3 written in solidity would be required, for starters.

If I understand correctly, you'd basically have to

  1. Get the uncompressed public key pub.
  2. Verify that keccak(pub[1:])[12:] == msg.sender
  3. Construct compressed key pubcos = 0x02 .. pub[1:33]
  4. Calculate sha256(pubcos) as s
  5. Calculate ripeMd(s) and arrive at addr.

At that point, you could 'connect' mgs.sender with addr.

Contributor

holiman commented Nov 16, 2017

@jaekwon @ebuchman Seems to be more complicated than I thought initally. From the seed phrase pasted above:

Private key, derived on path 44'/118'/0'/0/0:
	0x499c7dce161a8db03bfaa3a1035156250d932ac917b66e9c08c60b07a20a9dae
COS Public Key               : 0x02D7485091B95C158EEEC8ED2E248F7164BE5DF0956583DB3BB99F326390081CF8
COS Public Key (uncompressed): 0x04D7485091B95C158EEEC8ED2E248F7164BE5DF0956583DB3BB99F326390081CF8F334FDF8ACC7E22C69FDDEDD4FD46DBDDA4F6E635D6F5386350E079101FE5EA8
Eth public key               : 0x04D7485091B95C158EEEC8ED2E248F7164BE5DF0956583DB3BB99F326390081CF8F334FDF8ACC7E22C69FDDEDD4FD46DBDDA4F6E635D6F5386350E079101FE5EA8
Keccak256(pubBytes[1:]) 0xE2DE2CFE745900E94311C55B01E485D6B15E85764B1BE37FA71F2D57AF26B459
Keccak256(pubBytes[1:])[12:] 0x01E485D6B15E85764B1BE37FA71F2D57AF26B459
Public eth: 0x01E485D6B15E85764B1BE37FA71F2D57AF26B459
Cos Address: 0x4FB8FAB66EF33955F10D59B9B86183148858DBCE
Sha256(Cosmos Public Key): 0x88E01006EA89D0400A9FCC7224291FC7A231DEE00A03386A62AE8F4717E16CA7
Kec256(Cosmos Public Key): 0xF0F76DE539979DD340B5DD79F3E28A614F153D77F335245C7FA80DD143AEF7FE
Ripe160(Sha256(Cosmos Public Key)): 0x4FB8FAB66EF33955F10D59B9B86183148858DBCE
  • Cosmos appear to use compressed public keys, whereas ETH does not.
  • Eth ignores the first byte of the public key, whereas cosmos uses all.

So it's not just a matter of "add the missing 12 bytes of the sha3-hash and then do ripemd". I think e.g. a sha3 written in solidity would be required, for starters.

If I understand correctly, you'd basically have to

  1. Get the uncompressed public key pub.
  2. Verify that keccak(pub[1:])[12:] == msg.sender
  3. Construct compressed key pubcos = 0x02 .. pub[1:33]
  4. Calculate sha256(pubcos) as s
  5. Calculate ripeMd(s) and arrive at addr.

At that point, you could 'connect' mgs.sender with addr.

@ebuchman

This comment has been minimized.

Show comment
Hide comment
@ebuchman

ebuchman Nov 16, 2017

Thanks for adding more details and spelling out the process. That all sounds correct except the piece about sha3. Where do we use sha3 ? Also sha256 and ripemd160 are available as native contracts, so we shouldn't need to implement any hash functions in solidity. Am I missing something ?

ebuchman commented Nov 16, 2017

Thanks for adding more details and spelling out the process. That all sounds correct except the piece about sha3. Where do we use sha3 ? Also sha256 and ripemd160 are available as native contracts, so we shouldn't need to implement any hash functions in solidity. Am I missing something ?

@holiman

This comment has been minimized.

Show comment
Hide comment
@holiman

holiman Nov 16, 2017

Contributor

Doh, I was confused. I'll edit it. Yes, so it's perfectly doable.

    function testEthRecovery() constant returns(address){
        bytes memory ethpub = hex"04D7485091B95C158EEEC8ED2E248F7164BE5DF0956583DB3BB99F326390081CF8F334FDF8ACC7E22C69FDDEDD4FD46DBDDA4F6E635D6F5386350E079101FE5EA8";
        bytes memory clip   = hex"D7485091B95C158EEEC8ED2E248F7164BE5DF0956583DB3BB99F326390081CF8F334FDF8ACC7E22C69FDDEDD4FD46DBDDA4F6E635D6F5386350E079101FE5EA8";
        var eth_addr = keccak256(clip) ;
        // returns 0x1e485d6b15e85764b1be37fa71f2d57af26b459
        return address(eth_addr);
    }
    function testCosRecovery() constant returns (bytes20){
        bytes memory a = hex"02D7485091B95C158EEEC8ED2E248F7164BE5DF0956583DB3BB99F326390081CF8";
        var s = sha256(a);
        var b = ripemd160(s);
        // returns 0x4fb8fab66ef33955f10d59b9b86183148858dbce
        return b;
    }

So a possible amendment would be:

  • declareCosmosAddress(pubkey), which checks that the msg.sender corresponds to the pubkey, calculates the corresponding cosmos address, and allocates that number of futureTokens for msg.sender.
Contributor

holiman commented Nov 16, 2017

Doh, I was confused. I'll edit it. Yes, so it's perfectly doable.

    function testEthRecovery() constant returns(address){
        bytes memory ethpub = hex"04D7485091B95C158EEEC8ED2E248F7164BE5DF0956583DB3BB99F326390081CF8F334FDF8ACC7E22C69FDDEDD4FD46DBDDA4F6E635D6F5386350E079101FE5EA8";
        bytes memory clip   = hex"D7485091B95C158EEEC8ED2E248F7164BE5DF0956583DB3BB99F326390081CF8F334FDF8ACC7E22C69FDDEDD4FD46DBDDA4F6E635D6F5386350E079101FE5EA8";
        var eth_addr = keccak256(clip) ;
        // returns 0x1e485d6b15e85764b1be37fa71f2d57af26b459
        return address(eth_addr);
    }
    function testCosRecovery() constant returns (bytes20){
        bytes memory a = hex"02D7485091B95C158EEEC8ED2E248F7164BE5DF0956583DB3BB99F326390081CF8";
        var s = sha256(a);
        var b = ripemd160(s);
        // returns 0x4fb8fab66ef33955f10d59b9b86183148858dbce
        return b;
    }

So a possible amendment would be:

  • declareCosmosAddress(pubkey), which checks that the msg.sender corresponds to the pubkey, calculates the corresponding cosmos address, and allocates that number of futureTokens for msg.sender.
@Arachnid

This comment has been minimized.

Show comment
Hide comment
@Arachnid

Arachnid Nov 16, 2017

Collaborator

A suggestion: Perhaps it would make more sense to write a generic token contract, and implement specific subclasses of this contract for different recovery scenarios, with their own 'proof' functions.

Collaborator

Arachnid commented Nov 16, 2017

A suggestion: Perhaps it would make more sense to write a generic token contract, and implement specific subclasses of this contract for different recovery scenarios, with their own 'proof' functions.

@iFA88

This comment has been minimized.

Show comment
Hide comment
@iFA88

iFA88 Nov 18, 2017

Greetings, I need also some help with 100 stucked ETH on my contract. The ETH is stucked because the contract was badly coded and I can not withdraw my funds from them.

The contract address is: 0x9122e2cfab13d30237ebeef0c0521d64bf0b06dc
I have verified the source code too: etherscan
The contract is created by 0x3F2dA093Bb16EB064F8bfA9E30B929D15f8e1c4C TX
After the creation I have send 100 ETH to it: TX

Prove to that I own the 0x3F2dA093Bb16EB064F8bfA9E30B929D15f8e1c4C address private key:
msg: 2017.11.18. Please send my 100 ETH
msgHash: ed88c66defbcb5fba064613bb027630935c0c63625350a587caada00a4c745ed
sign: 0x1eb4a55da612f47e905811ae39a0d4b745e60de3b7f33d7fe5e652aa5e612e18e45ef2bfeda96e919772aeb5d4479066187fadfe45d5429da2cc2692832b4f3c1c

If you doing hardfork please send back the 100 ETH to the 0x3F2dA093Bb16EB064F8bfA9E30B929D15f8e1c4C address.

Thanks!

iFA88 commented Nov 18, 2017

Greetings, I need also some help with 100 stucked ETH on my contract. The ETH is stucked because the contract was badly coded and I can not withdraw my funds from them.

The contract address is: 0x9122e2cfab13d30237ebeef0c0521d64bf0b06dc
I have verified the source code too: etherscan
The contract is created by 0x3F2dA093Bb16EB064F8bfA9E30B929D15f8e1c4C TX
After the creation I have send 100 ETH to it: TX

Prove to that I own the 0x3F2dA093Bb16EB064F8bfA9E30B929D15f8e1c4C address private key:
msg: 2017.11.18. Please send my 100 ETH
msgHash: ed88c66defbcb5fba064613bb027630935c0c63625350a587caada00a4c745ed
sign: 0x1eb4a55da612f47e905811ae39a0d4b745e60de3b7f33d7fe5e652aa5e612e18e45ef2bfeda96e919772aeb5d4479066187fadfe45d5429da2cc2692832b4f3c1c

If you doing hardfork please send back the 100 ETH to the 0x3F2dA093Bb16EB064F8bfA9E30B929D15f8e1c4C address.

Thanks!

@Dsummers91

This comment has been minimized.

Show comment
Hide comment
@Dsummers91

Dsummers91 Nov 24, 2017

There was a reddit thread 8 months ago - Made a 1 ether contract last year to make a token. How do I recover the ether ?

Though I am not sure which solidity version it was compiled from, it has the same function/event hashes and the compiled assembly code seems to closely (but not exact) match to this contract code which came from the blog post - Ethereum in practice part 1: how to build your own cryptocurrency without touching a line of code. Seems like anyone can send funds to the contract but there is no way to get the funds out.

If we are able to return those funds that would be great

Contract Address: 0xb9550330bff5b4aada6afcbb6732442c74f80fd7
Tx Ether was sent: 0x32e1f0e51ed3486d18379a9053c69ca0cc4825209f889c0c6dd4afcfa0d7a086

Disclaimer: I am unaffected by this, just trying to help

Dsummers91 commented Nov 24, 2017

There was a reddit thread 8 months ago - Made a 1 ether contract last year to make a token. How do I recover the ether ?

Though I am not sure which solidity version it was compiled from, it has the same function/event hashes and the compiled assembly code seems to closely (but not exact) match to this contract code which came from the blog post - Ethereum in practice part 1: how to build your own cryptocurrency without touching a line of code. Seems like anyone can send funds to the contract but there is no way to get the funds out.

If we are able to return those funds that would be great

Contract Address: 0xb9550330bff5b4aada6afcbb6732442c74f80fd7
Tx Ether was sent: 0x32e1f0e51ed3486d18379a9053c69ca0cc4825209f889c0c6dd4afcfa0d7a086

Disclaimer: I am unaffected by this, just trying to help

@3esmit

This comment has been minimized.

Show comment
Hide comment
@3esmit

3esmit Nov 25, 2017

@Dsummers91 Lol, they can recover when they want, just call function "sell(amount of tokens they have)" in that token contract. https://etherscan.io/token/0xb9550330BfF5b4AADa6AfcBb6732442c74F80Fd7#balances

3esmit commented Nov 25, 2017

@Dsummers91 Lol, they can recover when they want, just call function "sell(amount of tokens they have)" in that token contract. https://etherscan.io/token/0xb9550330BfF5b4AADa6AfcBb6732442c74F80Fd7#balances

@Dsummers91

This comment has been minimized.

Show comment
Hide comment
@Dsummers91

Dsummers91 Nov 27, 2017

@3esmit I went through the function hashes from the assembly and only saw these.

0x06fdde03 - name()
0x313ce567 - decimals()
0x70a08231 - balanceOf()
0x95d89b41 - symbol()
0xa9059cbb - transfer()

The sell(uint256) - 0xe4849b32 doesnt exist in there, unless i am missing something..

Dsummers91 commented Nov 27, 2017

@3esmit I went through the function hashes from the assembly and only saw these.

0x06fdde03 - name()
0x313ce567 - decimals()
0x70a08231 - balanceOf()
0x95d89b41 - symbol()
0xa9059cbb - transfer()

The sell(uint256) - 0xe4849b32 doesnt exist in there, unless i am missing something..

@gkratoc1

This comment has been minimized.

Show comment
Hide comment
@gkratoc1

gkratoc1 Nov 28, 2017

Back in June I stumbled upon a previously undiscovered bug (or lack of failsafe) in Metamask for Firefox which permitted me to send 12.5 ETH to 0x0000000... and I have been watching EIP 156 ever since. I had almost accepted that the money was gone and never coming back before the latest Parity situation locked up so much more ETH than I lost, and I thought this might make this proposal easier to accept. I agree with everyone who has said that if it is possible to return the funds to people like myself who obviously had no intention of throwing their money into a black hole then it should be done. I hope there isn't serious consideration to return the large chunk of money to the big entities without taking care of the little guys who got burned along the way.

The transaction from my horrible day
https://etherscan.io/tx/0x92f699698908c348dcbaf6ecdcc0806dc5b6a08dab7f5df085f7ef070b369b5b

My review of Metamask describing the error is the last one on the list
https://addons.mozilla.org/en-US/firefox/addon/ether-metamask/reviews/

gkratoc1 commented Nov 28, 2017

Back in June I stumbled upon a previously undiscovered bug (or lack of failsafe) in Metamask for Firefox which permitted me to send 12.5 ETH to 0x0000000... and I have been watching EIP 156 ever since. I had almost accepted that the money was gone and never coming back before the latest Parity situation locked up so much more ETH than I lost, and I thought this might make this proposal easier to accept. I agree with everyone who has said that if it is possible to return the funds to people like myself who obviously had no intention of throwing their money into a black hole then it should be done. I hope there isn't serious consideration to return the large chunk of money to the big entities without taking care of the little guys who got burned along the way.

The transaction from my horrible day
https://etherscan.io/tx/0x92f699698908c348dcbaf6ecdcc0806dc5b6a08dab7f5df085f7ef070b369b5b

My review of Metamask describing the error is the last one on the list
https://addons.mozilla.org/en-US/firefox/addon/ether-metamask/reviews/

@3esmit

This comment has been minimized.

Show comment
Hide comment
@3esmit

3esmit Nov 30, 2017

@Dsummers91 That's sad. Seems like lots of people deployed this exact contract and throwed money there. There is one like this with more then 60 ETH https://etherscan.io/find-similiar-contracts?a=0xb9550330BfF5b4AADa6AfcBb6732442c74F80Fd7&lvl=5

3esmit commented Nov 30, 2017

@Dsummers91 That's sad. Seems like lots of people deployed this exact contract and throwed money there. There is one like this with more then 60 ETH https://etherscan.io/find-similiar-contracts?a=0xb9550330BfF5b4AADa6AfcBb6732442c74F80Fd7&lvl=5

@fivedogit

This comment has been minimized.

Show comment
Hide comment
@fivedogit

fivedogit Dec 1, 2017

"the proposal is created in order to allow community discussion and debate and does not signify full endorsement"

Just adding my support for this EIP. For cases where there was an obvious mistake made (funds sent to 0x contracts, etc), reversal is philosophically no different than, say, when geth returns an error on the command line instead of preventing a mistake. While the latter prevents the mistake entirely, the former simply reverses it.

More generally, I don't think changes accompanying hard forks must have technical improvement to be valid and implemented. I have no problem reversing objectively identifiable mistakes.

I'd also like to point out another class of "stuck" ether I haven't seen mentioned here: Ether sitting in valid contracts with no hope of withdrawal (now or ever). This happens when functions (or even the default function) of a contract don't explicitly return funds when an exception happens. My original (1.0) Etheria contract had such a bug and now has 4 ETH stuck on it because it was designed to be immutable and has no withdraw/suicide. (Indeed, the intention was for the contract to carry no balance at all.)

https://etherscan.io/address/0xe414716f017b5c1457bf98e985bccb135dff81f2

How it happened: In Etheria, users can perform several functions which require an amount of ETH to be sent along with the transaction: Buy a tile, farm a tile (more than once per interval), set their status, etc. In Etheria 1.0 and 1.1, if the user supplied some incorrect value of ETH or supplied ETH while trying to farm a tile they didn't own (among other exceptions), the function would simply return, eating the ETH supplied. I hadn't considered that eth must be refunded explicitly in these situations. Etheria 1.2 (final) contains such exception handling like the following:

function farmTile(uint8 col, uint8 row, int8 blocktype) public 
    { 	
    	Tile tile = tiles[col][row];
        if(tile.owner != tx.origin)
        {
        	tx.origin.send(msg.value); 		// return their money, if any
        	whathappened = "farmTile:ERR:not owner";
        	return;
        }
        ...
}

In short, this is a contract-level bug of the same variety as the Parity Multi-sig issue: contracts where it is mathematically provable that the balance has no way out (now or ever). The difficulty here is that if someone intended to "burn" ETH into a contract with no hope of escape, then a fork undoing Parity/Etheria stuck ether would counter their intent. But practically, I don't see this as a huge issue. Burning ETH forever makes no logical sense and I can't imagine anyone who may have done this for whatever reason would be upset getting their burnt ETH back.

So I'd say if we intend to reverse Parity, then we do a reversal of all contract-level stuck ether which can be logically proven to have no exodus path.

fivedogit commented Dec 1, 2017

"the proposal is created in order to allow community discussion and debate and does not signify full endorsement"

Just adding my support for this EIP. For cases where there was an obvious mistake made (funds sent to 0x contracts, etc), reversal is philosophically no different than, say, when geth returns an error on the command line instead of preventing a mistake. While the latter prevents the mistake entirely, the former simply reverses it.

More generally, I don't think changes accompanying hard forks must have technical improvement to be valid and implemented. I have no problem reversing objectively identifiable mistakes.

I'd also like to point out another class of "stuck" ether I haven't seen mentioned here: Ether sitting in valid contracts with no hope of withdrawal (now or ever). This happens when functions (or even the default function) of a contract don't explicitly return funds when an exception happens. My original (1.0) Etheria contract had such a bug and now has 4 ETH stuck on it because it was designed to be immutable and has no withdraw/suicide. (Indeed, the intention was for the contract to carry no balance at all.)

https://etherscan.io/address/0xe414716f017b5c1457bf98e985bccb135dff81f2

How it happened: In Etheria, users can perform several functions which require an amount of ETH to be sent along with the transaction: Buy a tile, farm a tile (more than once per interval), set their status, etc. In Etheria 1.0 and 1.1, if the user supplied some incorrect value of ETH or supplied ETH while trying to farm a tile they didn't own (among other exceptions), the function would simply return, eating the ETH supplied. I hadn't considered that eth must be refunded explicitly in these situations. Etheria 1.2 (final) contains such exception handling like the following:

function farmTile(uint8 col, uint8 row, int8 blocktype) public 
    { 	
    	Tile tile = tiles[col][row];
        if(tile.owner != tx.origin)
        {
        	tx.origin.send(msg.value); 		// return their money, if any
        	whathappened = "farmTile:ERR:not owner";
        	return;
        }
        ...
}

In short, this is a contract-level bug of the same variety as the Parity Multi-sig issue: contracts where it is mathematically provable that the balance has no way out (now or ever). The difficulty here is that if someone intended to "burn" ETH into a contract with no hope of escape, then a fork undoing Parity/Etheria stuck ether would counter their intent. But practically, I don't see this as a huge issue. Burning ETH forever makes no logical sense and I can't imagine anyone who may have done this for whatever reason would be upset getting their burnt ETH back.

So I'd say if we intend to reverse Parity, then we do a reversal of all contract-level stuck ether which can be logically proven to have no exodus path.

@tjayrush

This comment has been minimized.

Show comment
Hide comment
@tjayrush

tjayrush Dec 2, 2017

This comment is intended solely as social commentary. I intend to point out the inherent impossibility of drawing a clear, bright line between legit recovery of lost funds and not-so-obviously-legit recovery.

There is, as of this moment, $109,018,399.22 US, "stuck" in the DAO withdrawal contract. The community should figure out which accounts this money belongs to ("all the data is easily available in the blockchain...") and give the money back. It's the right thing to do. If some particular account has lost its key, then (if they can prove it) we can give them their money back later as part of some other hard fork.

If the community "solves" the lost ether problem for people who are technically adept enough to come to this web page to ask for it, then the community owes it to the less technical people (who can't figure out how to get their money out of the DAO) to return their money.

I don't actually believe what I've written here. I'm just trying to point out the danger of this type of EIP. This type of EIP won't "improve" Ethereum. The political (non-technical) ramifications may actually ruin Ethereum.

Disclosure: I have no ether stuck anywhere.

tjayrush commented Dec 2, 2017

This comment is intended solely as social commentary. I intend to point out the inherent impossibility of drawing a clear, bright line between legit recovery of lost funds and not-so-obviously-legit recovery.

There is, as of this moment, $109,018,399.22 US, "stuck" in the DAO withdrawal contract. The community should figure out which accounts this money belongs to ("all the data is easily available in the blockchain...") and give the money back. It's the right thing to do. If some particular account has lost its key, then (if they can prove it) we can give them their money back later as part of some other hard fork.

If the community "solves" the lost ether problem for people who are technically adept enough to come to this web page to ask for it, then the community owes it to the less technical people (who can't figure out how to get their money out of the DAO) to return their money.

I don't actually believe what I've written here. I'm just trying to point out the danger of this type of EIP. This type of EIP won't "improve" Ethereum. The political (non-technical) ramifications may actually ruin Ethereum.

Disclosure: I have no ether stuck anywhere.

@Arachnid

This comment has been minimized.

Show comment
Hide comment
@Arachnid

Arachnid Dec 2, 2017

Collaborator

I don't actually believe what I've written here. I'm just trying to point out the danger of this type of EIP. This type of EIP won't "improve" Ethereum. The political (non-technical) ramifications may actually ruin Ethereum.

I don't think constructing a straw man is a particularly good way to do that.

Collaborator

Arachnid commented Dec 2, 2017

I don't actually believe what I've written here. I'm just trying to point out the danger of this type of EIP. This type of EIP won't "improve" Ethereum. The political (non-technical) ramifications may actually ruin Ethereum.

I don't think constructing a straw man is a particularly good way to do that.

@gzduan

This comment has been minimized.

Show comment
Hide comment
@gzduan

gzduan Dec 25, 2017

If some particular account has lost its key, then (if they can prove it) we can give them their money back later as part of some other hard fork.

gzduan commented Dec 25, 2017

If some particular account has lost its key, then (if they can prove it) we can give them their money back later as part of some other hard fork.

@LefterisJP

This comment has been minimized.

Show comment
Hide comment
@LefterisJP

LefterisJP Dec 25, 2017

Contributor

If some particular account has lost its key, then (if they can prove it) we can give them their money back later as part of some other hard fork.

@gzduan how do you prove that you used to hold the private key for an account?

Contributor

LefterisJP commented Dec 25, 2017

If some particular account has lost its key, then (if they can prove it) we can give them their money back later as part of some other hard fork.

@gzduan how do you prove that you used to hold the private key for an account?

@winsvega

This comment has been minimized.

Show comment
Hide comment
@winsvega

winsvega Dec 25, 2017

Contributor

it is impossible to prove such a thing.
you could create some foundation that will payout compensations to those who lost founds by accident.

Contributor

winsvega commented Dec 25, 2017

it is impossible to prove such a thing.
you could create some foundation that will payout compensations to those who lost founds by accident.

@gzduan

This comment has been minimized.

Show comment
Hide comment
@gzduan

gzduan Dec 27, 2017

Can add a variable in the account, if it is 1 means someone have used the private key of this account , by default, all the variable of new account is 0, if someone used the private key of the account, this variable is automatically into 1. Otherwise the variable will always be 0, if you accidentally sent many tokens to the account that variable is 0 , the system will be in after a period of time, such as 3 years ,if this account still didn't have the records of using the private key, in other word,the variable is still 0. The system can identify the account as a black hole account and the money will be automatically returned.

The mistake of sending money to the black hole address, which is unavoidable, will continue to happen now, and this is the defect of the Ethereum network,

gzduan commented Dec 27, 2017

Can add a variable in the account, if it is 1 means someone have used the private key of this account , by default, all the variable of new account is 0, if someone used the private key of the account, this variable is automatically into 1. Otherwise the variable will always be 0, if you accidentally sent many tokens to the account that variable is 0 , the system will be in after a period of time, such as 3 years ,if this account still didn't have the records of using the private key, in other word,the variable is still 0. The system can identify the account as a black hole account and the money will be automatically returned.

The mistake of sending money to the black hole address, which is unavoidable, will continue to happen now, and this is the defect of the Ethereum network,

@fivedogit

This comment has been minimized.

Show comment
Hide comment
@fivedogit

fivedogit Dec 27, 2017

Well we've veered off the path from "mathematically provable ether stuck in contracts" into "ether stuck in accounts whose owners lost keys or passwords". (Unfortunately, I'm in this camp for a significant amount.) For the latter, I thought about this kind of "touch requirement" solution, too. i.e. Require a "touch" of accounts to prove they're not dead, then refund (to sender) those that remain untouched. Without asserting any opinion of my own, I can't imagine the community would allow any requirement like that. Longest of shots, IMO. One can hope, though, right?

Also note with regards to all kinds of stuck ether, there could be dependencies in contracts for an address's balance. ("If 0x123.balance = 5, do something, else do something else.") If we start refunding or reverting or whatever, it's possible conditions based on these balances could change. Shit, conditions based on the REFUND-TO account's balances could change. Although extremely rare, one would think, this is potentially dangerous. (So, personally, I'm back on the fence about whether or not to refund mathematically provable contract-stuck ether.)

fivedogit commented Dec 27, 2017

Well we've veered off the path from "mathematically provable ether stuck in contracts" into "ether stuck in accounts whose owners lost keys or passwords". (Unfortunately, I'm in this camp for a significant amount.) For the latter, I thought about this kind of "touch requirement" solution, too. i.e. Require a "touch" of accounts to prove they're not dead, then refund (to sender) those that remain untouched. Without asserting any opinion of my own, I can't imagine the community would allow any requirement like that. Longest of shots, IMO. One can hope, though, right?

Also note with regards to all kinds of stuck ether, there could be dependencies in contracts for an address's balance. ("If 0x123.balance = 5, do something, else do something else.") If we start refunding or reverting or whatever, it's possible conditions based on these balances could change. Shit, conditions based on the REFUND-TO account's balances could change. Although extremely rare, one would think, this is potentially dangerous. (So, personally, I'm back on the fence about whether or not to refund mathematically provable contract-stuck ether.)

@supRNurse

This comment has been minimized.

Show comment
Hide comment
@supRNurse

supRNurse Dec 27, 2017

Is there a way to isolate or quarantine indefinitely an address? If Ether is replaced from the un-spendable account (example my old friend the 0x0000...) can the zero address be isolated or quarantined in order to both prevent any future misdirected ETH landing there?

supRNurse commented Dec 27, 2017

Is there a way to isolate or quarantine indefinitely an address? If Ether is replaced from the un-spendable account (example my old friend the 0x0000...) can the zero address be isolated or quarantined in order to both prevent any future misdirected ETH landing there?

@winsvega

This comment has been minimized.

Show comment
Hide comment
@winsvega

winsvega Dec 28, 2017

Contributor

what you could do is to create another smart contract which would do all the logic you want.
lets say it will be insurance contract that would have a control of your founds. so if you lose key, you could initiate a procedure to claim your founds back. this way you wont need a hardfork.

then, if you are afraid that you loose you key, you just registrate your wallet at insurance contract / or should I say wallet contract.

it will have to be a really well written contract, though. as we dont want it to break again.

Contributor

winsvega commented Dec 28, 2017

what you could do is to create another smart contract which would do all the logic you want.
lets say it will be insurance contract that would have a control of your founds. so if you lose key, you could initiate a procedure to claim your founds back. this way you wont need a hardfork.

then, if you are afraid that you loose you key, you just registrate your wallet at insurance contract / or should I say wallet contract.

it will have to be a really well written contract, though. as we dont want it to break again.

@gzduan

This comment has been minimized.

Show comment
Hide comment
@gzduan

gzduan Dec 28, 2017

Can add a variable in the account, if it is 1 means someone have used the private key of this account , by default, all the variable of new account is 0, if someone used the private key of the account, this variable is automatically into 1. Otherwise the variable will always be 0, if you accidentally sent many tokens to the account that variable is 0 , the system will be in after a period of time, such as 3 years ,if this account still didn't have the records of using the private key, in other word,the variable is still 0. The system can identify the account as a black hole account and the money will be automatically returned.
The mistake of sending money to the black hole address, which is unavoidable, will continue to happen now, and this is the defect of the Ethereum network。
This similar to activate an account,if there have the record of using private key on the blockchain, the account will be automatically activated and will not returned the eth after received the eth three years , the use of paper wallet does is restricted, because there must be activated account operation, but this only to new accounts which private key never used by people , maybe paper wallets are not a necessary a way of storing tokens, Cold wallet signature can be a good choice, can use the private key offline and ensure absolute safety.
Put the tokens sent to the a black hole accounts always happen to us, on the one hand block chain technology ensures the property safety of people, but the careless operation is so despair to ethereum users .the proposal can effectively recover the eth that sent to a black hole account , at the same time ,it also punished the careless users, Because they have to wait at least three years to get the money they lost because of their mistakes.

gzduan commented Dec 28, 2017

Can add a variable in the account, if it is 1 means someone have used the private key of this account , by default, all the variable of new account is 0, if someone used the private key of the account, this variable is automatically into 1. Otherwise the variable will always be 0, if you accidentally sent many tokens to the account that variable is 0 , the system will be in after a period of time, such as 3 years ,if this account still didn't have the records of using the private key, in other word,the variable is still 0. The system can identify the account as a black hole account and the money will be automatically returned.
The mistake of sending money to the black hole address, which is unavoidable, will continue to happen now, and this is the defect of the Ethereum network。
This similar to activate an account,if there have the record of using private key on the blockchain, the account will be automatically activated and will not returned the eth after received the eth three years , the use of paper wallet does is restricted, because there must be activated account operation, but this only to new accounts which private key never used by people , maybe paper wallets are not a necessary a way of storing tokens, Cold wallet signature can be a good choice, can use the private key offline and ensure absolute safety.
Put the tokens sent to the a black hole accounts always happen to us, on the one hand block chain technology ensures the property safety of people, but the careless operation is so despair to ethereum users .the proposal can effectively recover the eth that sent to a black hole account , at the same time ,it also punished the careless users, Because they have to wait at least three years to get the money they lost because of their mistakes.

@winsvega

This comment has been minimized.

Show comment
Hide comment
@winsvega

winsvega Dec 28, 2017

Contributor

no need to add such a flag.
if there is a transaction in the network from this account then someone has it's private key,
if there is no transaction from this account, then someone still could have it's private key.

Contributor

winsvega commented Dec 28, 2017

no need to add such a flag.
if there is a transaction in the network from this account then someone has it's private key,
if there is no transaction from this account, then someone still could have it's private key.

@gzduan

This comment has been minimized.

Show comment
Hide comment
@gzduan

gzduan Jan 1, 2018

It's like you have to bind a phone number when you use Facebook account

gzduan commented Jan 1, 2018

It's like you have to bind a phone number when you use Facebook account

@Muhammad-Altabba

This comment has been minimized.

Show comment
Hide comment
@Muhammad-Altabba

Muhammad-Altabba May 3, 2018

What about tokens? Is it to be considered in this EIP, or should I open a separate issue?
A reported case: https://www.reddit.com/r/ethereum/comments/5rd4co/ethereum_wallet_sends_to/

Muhammad-Altabba commented May 3, 2018

What about tokens? Is it to be considered in this EIP, or should I open a separate issue?
A reported case: https://www.reddit.com/r/ethereum/comments/5rd4co/ethereum_wallet_sends_to/

@5chdn

This comment has been minimized.

Show comment
Hide comment
@5chdn

5chdn May 7, 2018

Contributor

Tokens can be recovered on layer 2 and are out of the scope of this proposal, from what I understand.

Contributor

5chdn commented May 7, 2018

Tokens can be recovered on layer 2 and are out of the scope of this proposal, from what I understand.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment