I suggest reading @alexvandesande’s write-up of an alternative solution to lost ether.
Basically, what’s described is a “recovery contract” concept where beneficiaries of lost ether are distributed an ERC20 token at a 1:1 ratio. The recovery tokens can be redeemed pro rata for some amount ETH, with the potential source being from donations, EIP1015 (basically a tax on PoS) and possibly insurance.
What value does this provide over full recovery? If we go through the effort of recovering, why not do the whole thing?
This assumes the fork would be damaging (net). I’m not convinced of that. It is possible that knowing that Ethereum is willing to do no-contest fund recovery could incentivize further interest in the platform due to a risk reduction compared to a fully immutable system. There are of course arguments on the other side that it will damage confidence, but at the moment it is all speculation.
I have seen this proposed a few times, and it has never been clear to me why anyone would ever want those tokens. They have no potential future value for network fees, nor do they have any future utility. Also, why would anyone voluntarily give away their ETH (donate) to such a thing with no guarantee that everyone will donate equally?
It’s not my idea, so I’m not a good authority on this topic. However I can think of two reasons why somebody might donate to a recovery fund:
Whether these donations would be significant – I don’t know. Of course, it wouldn’t get close to the original sum lost.
It’s not my proposal, but I prefer it over an involuntary contribution from all to the affected parties. Your questions are probably better directed at @alexvandesande or someone else backing it.
@alexvandesande addresses this question in his post. His proposal involves building an insurance marketplace where those tokens collect fees in the future.
If I’m following the argument correctly, it starts off with the assertion that the client dev teams (besides Parity) will not include recovery in a hard fork. That means the arguments it makes are not relevant to whether or not client dev teams should include recovery in a hard fork, which is what mast of the discussion is about.
As far as the token thing, it needs funding to be worth anything and each of the proposed funding items have problems:
I mostly agree with @MicahZoltu. While working on EIP-867, I saw many people say things like “I hope you’re considering non-hard-fork solutions as well”, so I asked around and tried to collect a list of recovery options that didn’t require a hard fork. The only two options I found were:
I don’t see Option 1 as viable to address past issues. I didn’t really understand @alexvandesande’s point toward the end of the article about why an insurance company would voluntarily take on enormous liabilities on Day 1. Even if some well meaning person wanted to, what investor would fund them?
Also, even for future incidents I’m skeptical. Imagine an insurance company starts up and is wildly successful. It pays out some small claims while making a great profit. Everyone is happy. Then, the big one hits. Why wouldn’t it push for a fork? It would potentially have huge resources available to run an aggressive PR/legal campaign.
For Option 2, I had considered that the recovery token contract would be funded by future recovery. At best, this would postpone a fork, and at worst it would just dupe a lot of people into buying worthless tokens. Alex did not make this assumption, but I think some of my other pros/cons still apply.
Pros
Cons
I’m not entirely opposed to this approach, but these are the reasons I originally dismissed it. In the end, I think if people are willing to allocate recovery tokens and then allocate blocks rewards to back them, I don’t see why they wouldn’t be willing to just recover the funds in one go and avoid all this complexity and risk.
That’s simply not true - the fundamental difference of a blockchain isn’t that you can’t change it, it’s that you can’t change it without everyone’s involvement and consent.
Why would you fetishise ossification like that?
What losses are being socialized?
Doesn’t locking up ether “change the available supply in an unpredictable fashion”?
Everyone’s? Taken literally, it’s exactly what I wrote
a decentralized system requires unanimous agreement
yet clearly you don’t agree. So what do you actually mean by ‘everyone’?
I think we aren’t being very clear with the description of what the blockchain can and cannot do. Here’s a start, but please feel free to suggest changes … I’m sure I’m oversimplifying or just plain wrong in some cases (although not as egregiously as three word marketing slogans), but it’s a start…
A blockchain gives independent nodes an efficient way to determine if their local version of history agrees with another node’s version of history. If they are identical, the block hashes will match. If they aren’t, they won’t, and the two nodes will know that there is some discrepancy.
Anyone is free to make any change they want, anytime time they want, without anyone’s permission. However, the change will be detected and rejected by other nodes unless they also make the same change. A single person can split the chain – the extent to which is matters to everyone else is dependent on how many other people use that version of the chain.
The history of the blockchain is immutable only for a given block hash. In theory, there are actually many versions of history that could produce a given block hash, although we assume only one such sequence of blocks will ever be known, and it will only be known if the hash is computed from history (not the other way around).
The ledger, as an ongoing concern, is not immutable. It mutates with every transaction that is included in a block. If it were immutable, everyone’s balance would be zero (and that multisig library contract if somehow it were able to appear on a truly immutable system could not have been deleted, right?). Claiming that a change cannot be injected into the blockchain in the future because “the blockchain is immutable” doesn’t make any sense.
Changes to the blockchain are automatically permitted when a submitted transaction follows a pre-defined set of rules. i.e. if I hold the private key for account X, and I submit a transaction that will send ETH from account X to account Y. Note, in this case, the rules permit me to mutate Y’s account balance without Y’s consent. You could imagine a blockchain in which the rules do not permit this.
The rules of the blockchain system are not necessarily fixed. This is especially true in the case of Ethereum, where plans to regularly hard fork to upgrade the chain were expected from the very beginning. That is, part of the rules were that you could change the rules.
There are rules about changing the rules, but we probably can’t fully describe them.
Weird idea.
When Bitcoin Cash and Ethereum Classic forked the lesser-accepted chain settled at about 10-20% of the other chain’s value. Therefore, if Ethereum forks over this issue, participants in one or the other chain should probably expect a loss in the value of their holdings. Those who are holding locked ether would be better off than they currently are, but they would not recover the full ‘nominal’ value of the ether. The other side would probably see a diminution of their value as well because of the controversy. Both sides lose.
Alternatively, if the two sides agree not to fork, the locked ether could be recovered, but a “fencing” penalty could be extracted by burning 50% of the unlocked ether. An agreement such as this, I think, would be good for the community. The holders of the locked ether might expect to get a higher value than if the chain contentiously forks (if theirs becomes the lesser-accepted chain – the same argument can be made from the other side as well). Both sides might win.
I don’t think this will ever happen. Nor do I necessarily think it should, but I thought I’d throw it out there just to see what you’all think. If I had to express a preference, I would say do not recover the lost ether because the alternatives (including this idea) are worse.
I just listened to the April 20 core devs meeting recording. My opinion is that consensus on EIP 999 is not going to be achieved. There are at least a few highly motivated and vocal people who are consistently against any recovery of funds. I believe these people are a small minority, but I admit that it is hard to judge. That’s why I think consensus is unlikely. Since consensus is unachievable, I think we must embrace a contentious hard fork. I support EIP 999. I would like to see clients offer the option of EIP 999. I believe the vast majority of miners and other people who run clients will support EIP 999. Many of these people may be silent and prefer not to get involved in argument. That’s why I decided to speak up myself. I don’t want to argue about EIP 999. I just support EIP 999 and want to see it offered as an option that I think the vast majority of silent people will support.
Consider that it’s possible that the cost to ether stakeholders who didn’t use insecure smart contracts & lose funds in a parity multisig wallet would be greater in the event of a chain split than would be the value recovered by those with funds in the wallets in question. A chain split is simultaneously an act of creation (by means of creation of new tokens) & destruction (by means of dilution and the introduction of new problems of user confusion, which have real economic costs to users who didn’t lose funds). And I think a chain split is guaranteed to happen if we follow through with EIP-999. If the project of Ethereum is that we’re attempting to build, in some sense, an immutable actual free market, then using governance to introduce economic shocks into the system seems to defeat a huge part of the rationale which attracted many of us to Ethereum in the first place – namely, to design systems which could not be interrupted by even the tyranny of the majority – unless users consented to being governed by that majority. By holding the token, we have not consented to arbitrary violations of immutability, even ones decided by a governance process. The only thing users consent to by holding ether is participation in an immutable network which allows the transfer and use of that ether token.
If we’re speaking in general terms about the question of ‘under what circumstances should immutability be violated to protect users,’ where exactly do we draw the line? How is my accidentally sending funds to a non-existent address no less viable of a reason for eth users to come to social consensus on violating immutability to bail me out? As a community, do we have a standard on what activity qualifies for a bailout? If so, what is that standard?
I personally think ether should never be rescued for users with a governance process sanctioned violation of immutability. If a user wants to create a token on-chain with its own governance logic built in that allows for arbitrary violations of immutability to be made based on some vote of individuals who use the token, more power to them in building those systems and storing value that way in their own system with virtual governance. I think it should be enforced via community norms that users should understand that when interacting with the ethereum token & network, the ‘social contract’ we’re signing up to is that if we want to continue participating in the ethereum mainnet, we accept that contract code runs as it is written, with no recourse for bugs in contract logic available via violations of immutability in the EIP process.
I try to say this respectfully to all users who lost funds in a parity multisig wallet.
To understand why I support this EIP, I expose the premises my reasoning starts from.
About this specific EIP
At the end this EIP simply restores a state of the chain where multisig wallets can work again, no one loses ethers, tokens or whatever and no one gains them. This seems legit enough to me, and this is why I support this EIP.
The problem with EIP 867 is that it only works for large holders. Someone losing 5 ETH in a provable fashion will be of much lower priority than someone losing 10000 ETH. EIP 867 will just spawn more EIP 999 style discussion. There will be disagreements over the intended semantics of contracts and the fairness of recovering funds.
Moreover, support of EIP 867 begs the question, how do you prove that the parity multi-sig wallet did not behave correctly. Is it absurd the fathom that a contract can burn collected ETH using the self-destruct mechanism?
I think the main problem people will have is that EIP 999 and even EIP 867 will be an example of a system working to absolve the errors of wealthy stakeholders, without regard to other stakeholder.
I believe that in the future Recoverable Tokens (EIP 1080) will be able to provide an opt-in solution for all who want the added safety.
What makes you believe this? The way 867 is written, it makes this explicitly not the case and a proper recovery proposal that recovered 1 attoeth would be more valid than an improper proposal that recovered 1 megaeth.
The plain nature of the situation is that people with more at state will have more incentives to comply technically and promote token recovery to debs.
EIP-999 is a great example of this.
I don’t think Jenny from the block would be able to get a core dev to even consider her proposal. Especially because it’s mostly not obvious what contract features are bugs and which are features or which transfers are purposeful and which are accidental.
There must be some barrier to entry to prevent spam/denial-of-service. Jenny can solicit help from others to craft the ERP, and whether a proposal is valid or not is what determines whether the core team will look at it, not how much ETH it recovers. It is the EIP editors’ job to give Jenny feedback on the ERP so that by the time it is in front of the core devs it is already well formed and ready to go. With a standardized mechanism for recovery, implementation by the various dev teams is near zero (after the first) because the ERP provides a standard format for recovery that the clients can just plug in.
The argument it sounds like you are making is that we should recover no one’s ETH because some subset of users do not have the means or motivation to complete the ERP process. This, IMO, is just catering to the lowest common denominator. Considering how easy (relatively) the proposed ERP process is I think that this is far too extreme of a position to take.
How do we define this barrier to entry, it’s very important to understanding 867.
Also, how do you prove to the core devs that a contracts semantics ought to be different that were written or that a transaction should have never happened? Sending Eth to the 0x or not-yet-created address are not sufficient tests as this is used to burn money or send money to people who haven’t broadcasted their account yet.
Moreover, if it weren’t for the popularity and marketing around the Parity Multisig wallet, I would have no way of knowing that people didn’t expect that self-destruct switch to be a sort of Eth burning mechanism. I only have a good level of certainty here because of the size and marketing around the players involved. (If only size and marketing came with auditing)
Without a definition of the barrier to entry, I am assuming that the process will take place in a similar fashion as recoveries through the core devs have always taken place. We have considered two recoveries: the DAO and EIP-999. No small recoveries were ever considered.
Thus I think this subset of users is the vast majority of users besides maybe the 20 top accounts.
This is because, I believe, crafting a PR to do a recovery is incredibly hard for the average user. The ERP process attempts to simplify that process significantly such that you do not have to be an Ethereum client developer to understand how to craft such a recovery. It still requires some understanding of how Ethereum works, in particular how trustless systems work (no one is going to just “take your word for it”, but it doesn’t require you to understand the inner workings of Ethereum clients.
This is the “reasonable human” test. For all of the proposed cases (big or small) for the ERP process none of them have resulted in someone truly believing that the losses were intentional. For example, there is no reasonable argument to a human of average intelligent that the ICO who posted a JavaScript truncated address to their website intended to do that in order to cause people to burn money that was intended to go to them. Similarly, there isn’t a reasonable argument that someone would intentionally send funds to an address that is off-by-one-byte from a real address that has seen real use. For the Parity case it is obvious to a reasonable human that the intent of the wallet wasn’t designed (by Parity) so that someone could burn everyone’s money (including the author’s). The wallet was clearly advertised and used (by the author) as a form of secure storage.
Part of the ERP process is to provide an argument as to why you believe your ETH should be recovered, which means providing an argument like the above examples (though of course more in-depth and well written). The purpose of this argument is to convince a reasonable human that the funds are inaccessible due to an accident. Anyone can refute your argument and it is up to reasonable humans to decide if the refutation instills enough doubt to block the recovery.
@bradleat Out of curiosity, would you be more open to this EIP if it were preceded by a successful recovery of one of the other causes of losses that effects more “normal” users (like off-by-one-byte address)? There is some ETH lost to address typos that could be recovered, but no one has bothered to draft a PR for it yet.
For those that say immutability at all costs, well, there’s not much to discuss—there simply exists no sufficient condition for recovery.
For those that do think there exists a sufficient condition for doing a recovery, what do we think of the “considerable example”, given in the EIP-867 spec? If this is deemed insufficient, what would be an even more compelling example? For reference, I reproduce it below:
Considerable example (concise, includes supporting evidence, no negative impact): A crowdsale run by XYZ incorrectly published the testnet address of their crowdsale contract to their public website at the start of their crowdsale on Jan 19, 2018. 501 ETH was sent by 328 users on the mainnet to the incorrect address between block 4,235,987 and 4,236,050. See here for the testnet contract, and see here for the transactions to the same address on the mainnet. See here for a statement made by XYZ on their website. Because there is a contract at this address on the testnet and the corresponding nonce for the creator address has already been used on the mainnet, it is considered effectively impossible that anyone coincidentally holds the private key. We have verified that all transactions came from addresses with no associated code, so there should be no issue returning eth to the senders.
I would like to come up with the most steelman’ed example(s) possible for recovering funds. We could then set an incredibly high standard of: “Unless your recovery meets this incredibly high standard, the answer is no.” This would allow us to have more clarity for what sort of recoveries would be done instead of the current vagueness.
For those into immutability (which include myself), we obviously want these recoveries to meet incredibly high standards. And when Plasma chains become more of a thing, it becomes more sensible for us to forbid recoveries on the main chain. But we aren’t there yet. So until then I would like to come up with the most steelman’ed example(s) possible that have the most support for recovery. And when the side-chains become a thing, then we can re-open the issue as to whether to forbid recoveries at all on the main chain.