Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Reclaiming of ether in common classes of stuck accounts #156

Closed
vbuterin opened this issue Oct 14, 2016 · 123 comments
Closed

Reclaiming of ether in common classes of stuck accounts #156

vbuterin opened this issue Oct 14, 2016 · 123 comments
Labels
stale

Comments

@vbuterin
Copy link
Contributor

vbuterin commented Oct 14, 2016 •
edited by Pandapip1
Loading

The discussion link has been migrated to https://ethereum-magicians.org/t/reclaiming-of-ether-in-common-classes-of-stuck-accounts/16111

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
Copy link

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.

@trapp
Copy link

trapp commented Oct 16, 2016

Here are some reports of affected users and implementations:

@Smithgift
Copy link

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
Copy link
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
Copy link

trapp commented Dec 4, 2016 •
edited
Loading

@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
Copy link

Another thread related to this EIP:
https://www.reddit.com/r/ethereum/comments/5rd4co/ethereum_wallet_sends_to/

@GriffGreen
Copy link

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
Copy link

@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
Copy link

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
Copy link
Contributor

Souptacular commented Jun 6, 2017 •
edited
Loading

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
Copy link

mjmau commented Jun 8, 2017 •
edited
Loading

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
Copy link

netpro2k commented Jun 8, 2017 •
edited
Loading

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
Copy link
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
Copy link
Contributor

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
Copy link
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
Copy link
Contributor

winsvega commented Jun 16, 2017 •
edited
Loading

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
Copy link

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
Copy link

sardoru commented Jul 9, 2017 •
edited
Loading

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
Copy link

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
Copy link

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
Copy link

@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
Copy link

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
Copy link
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
Copy link
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?

@mjmau
Copy link

mjmau commented Aug 16, 2017 •
edited
Loading

@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
Copy link

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
Copy link
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.

@plutoegg
Copy link

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
Copy link
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.

@jaytoday
Copy link

@plutoegg do you think in practical terms the willingness of ETH2 clients to monitor a deposit contract that would allow for lostETH to be staked would be that different than implementing the change in ETH1? A lot of the same concerns would still apply. I think the one thing that could end a hope of this working is the possibility of a contentious fork, aka "ETH2 Classic".

One of the considerations would be how this deposit contract actually issues lostETH, making sure it can't be abused, etc.

Is anyone actually working on this deposit contract based approach to this problem? It seems like the window for it would be in the next few months.

@jespow Would the addresses and balances need to be hard-coded in client code or is there some other mechanism to implement this?

This could be implemented using a similar mechanism proposed by Vitalik in 2016 at the start of the thread - using an ERC20 token which distributes lostETH to all affected by the various cases of lost ETH.

An alternate ETH2 deposit contract would then need to be deployed, accepting deposits of lostETH instead of ETH. ETH2 clients therefore would not need to have any hard-coded addresses or balances, but would need to monitor this second deposit contract for valid deposits, as well as the main deposit contract.

@jacponer
Copy link

Am i also trapped in the black hole? I dont have much knowledge about the chain but can anybody explain this:

Hi, today i sendend a order of 1051 sxp to this adress 0x085a36A9d73abcd18417A9Abe3bA4bc3cB3a51BC by accident. Now i can`t reach this wallet. After some research is saw this is a contract wallet of binance. Can u guys help me to get my coins back? This is the orderadress: https://etherscan.io/token/0x8ce9137d39326ad0cd6491fb5cc0cba0e089b6a9?a=0x085a36a9d73abcd18417a9abe3ba4bc3cb3a51bc

With kind regards,

Gerbert Pater

@holiman
Copy link
Contributor

holiman commented Feb 10, 2021

today i sendend a order of 1051 sxp to this adress 0x085a36A9d73abcd18417A9Abe3bA4bc3cB3a51BC by accident. Now i can`t reach this wallet. After some research is saw this is a contract wallet of binance.

The sxp was sent here:https://etherscan.io/address/0x085a36A9d73abcd18417A9Abe3bA4bc3cB3a51BC . I don't know why you think it's a contract-wallet of binance, as far as I can see there's no code deployed, nor has the address ever been used. Which means that yes, it seems the tokens are trapped in a black hole (caveat: I know nothing about that token, and since it's not ether but a token, it's totally up to the token how funds are managed. A token could e.g. have rollbacks or ways to admin-override balances, it's theoretically possible (if unlikely))

@jacponer
Copy link

today i sendend a order of 1051 sxp to this adress 0x085a36A9d73abcd18417A9Abe3bA4bc3cB3a51BC by accident. Now i can`t reach this wallet. After some research is saw this is a contract wallet of binance.

The sxp was sent here:https://etherscan.io/address/0x085a36A9d73abcd18417A9Abe3bA4bc3cB3a51BC . I don't know why you think it's a contract-wallet of binance, as far as I can see there's no code deployed, nor has the address ever been used. Which means that yes, it seems the tokens are trapped in a black hole (caveat: I know nothing about that token, and since it's not ether but a token, it's totally up to the token how funds are managed. A token could e.g. have rollbacks or ways to admin-override balances, it's theoretically possible (if unlikely))

Ai.. this means i lost the coins forever?

@holiman
Copy link
Contributor

holiman commented Feb 10, 2021

As far as I can tell, yes

@jacponer
Copy link

Hmm, that sucks :) But is it not possible to find this wallet somewhere?

@djoq
Copy link

djoq commented Feb 15, 2021

I am faced with a similar issue on behalf of a customer. I have no idea how this happened, but he had an address he was trying to send to that ended in 0x...b880 (which is an exchange address and he has no access to private key) and the coins ended up going to the exact same address with the exception of the last two chars, and got locked in 0x...b879.

If he did have the private key, could the private key be computed of the mistaken address at any reduced cost computationally, knowing the private key of another address differing by a few bytes?

@masaruduy
Copy link

Some time ago, in 2017, I was using Metamask as a newbie with an interface which still really needed work. I went and decided to create a contract with only 0x in its code and sent 2.5 eth to it. Will this or other EIP help me get back the funds?

Thanks!

@supRNurse
Copy link

Believe me I pray it would.. but I haven’t seen any traction trying to move it forward. I can’t see how stranded ETH in the zero addresses utilized this way would be a negative to the integrity of the blockchain.

@masaruduy
Copy link

Believe me I pray it would.. but I haven’t seen any traction trying to move it forward. I can’t see how stranded ETH in the zero addresses utilized this way would be a negative to the integrity of the blockchain.

When you say zero addresses, do these include empty contracts?

@masaruduy
Copy link

masaruduy commented Apr 27, 2021 •
edited
Loading

Also, how do we push it?! It's starting to feel like forces HODLing :)

@tjayrush
Copy link

tjayrush commented Apr 27, 2021 •
edited
Loading

Believe me I pray it would.. but I haven’t seen any traction trying to move it forward. I can’t see how stranded ETH in the zero addresses utilized this way would be a negative to the integrity of the blockchain.

Not to get involved in this conversation (I won't), but I just wanted to say that sometimes people purposefully send ETH to the zero address as a way to burn the ETH. This lowers the number of coins in existence and thereby increases the value of each remaining coin. Recovering that ETH would violate those person's purposeful action. Violating purposeful action seems to be a pretty huge negative to ETH's integrity to me.

The other obvious problem with the suggestion of recovering the ETH currently in the zero address is who gets to decide what to do with it?

There's zero traction on this issue because there's zero good directions to move forward.

@supRNurse
Copy link

supRNurse commented Apr 27, 2021 via email

@supRNurse
Copy link

supRNurse commented Apr 27, 2021 via email

@masaruduy
Copy link

masaruduy commented Apr 28, 2021 via email

@supRNurse
Copy link

supRNurse commented Apr 29, 2021 via email

@masaruduy
Copy link

masaruduy commented Apr 29, 2021 via email

@rkagerer
Copy link

rkagerer commented Apr 29, 2021 •
edited
Loading

There are likewise some 17,000+ victims of the Quadriga hack who would benefit if a mechanism like the one discussed here could recover the 67,000 ETH that got locked up in their splitter contract when the company upgraded from Geth 1.5.3 to 1.5.9 (@axelay alluded to this in his 2015 comment). That amount would have a real impact on the pot available for distribution.

@github-actions
Copy link

github-actions bot commented Jan 8, 2022

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

@github-actions github-actions bot added the stale label Jan 8, 2022
@Muhammad-Altabba
Copy link
Contributor

I hope to find a solution for this soon.
Thanks,

@github-actions github-actions bot removed the stale label Jan 8, 2022
@github-actions
Copy link

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.

@Lucienest
Copy link

When you're doing this?

@djoq
Copy link

djoq commented Feb 15, 2022 via email

@Luigy-Lemon
Copy link

Luigy-Lemon commented Oct 15, 2023 •
edited
Loading

This issue seems to be trending back up again...
https://dune.com/queries/1941703?d=11

If people don't want to allow this to be reverted is one thing, it can tricky, but why has there been no fix to the cause of the problem after 7 years?
Do not allow wallets to send null transactions to the null address with a positive ether value!
It seems like such a straighforward rule. Does anyone know the real reason why it has not been addressed?

@ethereum ethereum locked as off-topic and limited conversation to collaborators Oct 16, 2023
@Pandapip1
Copy link
Member

This is no longer the correct place to discuss this anymore. I have created a thread on FEM to continue the conversation: https://ethereum-magicians.org/t/reclaiming-of-ether-in-common-classes-of-stuck-accounts/16111

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
stale
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests