EIP-867: Standardized Ethereum Recovery Proposals (ERPs)

EIPs
17

This is the bit that, in my opinion, makes it so that any funds currently controlled by an individual (e.g., TheDAO hacker) would not qualify for going through the ERP process (emphasis mine):

This EIP describes a common format to be used for a subclass of EIPs […] that propose an irregular state change required to address a fund recovery scenario that cannot be addressed using the standard protocol.

If there exists a private key known by someone (or possibly known by someone) that has access to the assets in question, then it is possible to handle the recovery via the standard protocol (e.g., via an ETH transfer transaction).

@phiferd, there may be value in making this a bit more plain/obvious/clear. While I do think the above quote technically creates that requirement, to the average reader it is not obvious on first glance.

18

@MicahZoltu is correct in his interpretation. I’m certainly open to rewording if there’s a better way to phrase it.

For directly affected, let’s start with a simple example.

A → B*, where A is a regular account and B* is a off-by-one typo of address B, which is also a regular account (i.e. not a contract).

In this case, there are clearly two “directly affected” parties: A and B. The owner of address C doesn’t have any provable involvement in the transaction. If we agree that private property exists on the blockchain (I don’t think everyone here does), then A and B are the only two people that really have anything to say about what the “right” solution is. The ERP process (explicitly) only applies in cases where A and B agree on the solution.

No. In the example above, C cannot just arbitrarily claim to be affected.

If B is in jail and A claims that funds in B* should be sent to A, then the agreement requirement cannot be met. In that case, a B would likely challenge. However, if A agrees that the funds in B* should go to B, then B’s permission probably isn’t required (after all, A can send funds to B anytime he wants without B’s permission).

Can it be more complicated? Of course. However, the ERP process was not meant to handle all cases. Rather than saying “here are 50 scenarios we can’t solve” we tried to carve out a boundary around cases that we can solve.

19

Thanks @MicahZoltu, I want to address your points and possibly clear up any misunderstandings you have regarding property rights.

Layer 2 is just as susceptible as Layer 1. Yes, I never disagreed here. The bonus is that your project may now implement whatever degree of fiat that it needs. Which is the spirit of the ERP - To what degree will Ethereum users allow for Fiat in their network? It should be sandboxed as far away from the chain as possible. Preferably left to the legacy banking system

As Fiat would represent a backwards incompatible and breaking feature for the current user base the only compromise is for projects wishing to include Fiat-as-a-Feature (FaaF) to do so moving forward, in their own projects. Not as a network solution to a problem specific to a single project.

I love your point about multisig and interacting with other contracts. I will update the ERP spec - Projects that implement the Ethereum Recovery Proposal should only interact with other Projects that implement the Ethereum Recovery Proposal. Thank you.

This will protect other teams from projects that require they test their beta product in production.

Now then, let’s talk about property rights…

If you own a bar of gold and throw it in the Marianas Trench, I agree you can make a case that you still own that gold. This would be tantamount to a user miss-typing the receiving address of a transaction.

But to me, that’s a valid transaction. Code is Law the same way we will not rewrite the laws of physics to reclaim the bar of gold.

The argument for an ERP that changes the fundamentals of the protocols binding Ethereum together is frustrating because it relies on sliding the goal post - The Slippery Slope. Its already happening right now. Code is Law so you pose “Let’s move where the line is for the Code.” While that is clever, it shows a belligerent misunderstanding of the environment and its users.

Even the definitions of property rights are subject in this upside down argument. For if we were to apply your airy and nebulous standard to current users the network would break. I could just as easily claim every tx ever sent by me was a mistake and force this very human process to decide who owns what funds - no different from a banking system.

The user was the only person able to send those funds down a black hole. They did. Part of the responsibility of owning property is that you can make mistakes. It is a fundamental failure of property rights to grant one group some exclusive privilege. In this case, the ability to reverse their transaction.

Furthermore, there are many more perfectly legitimate use cases where a user would burn a coin - sending to address(0) for instance. Since your proposal relies on a human fiat process to determine if funds were sent incorrectly the only option you have is a layer 2 solution.

As this entire proposal is nothing more than a single project (Parity) masquerading their required change as a required change to the core fundamentals that govern the Ethereum network is ultimately elitist favoritism toward a tiny group I think we should put an end to the masquerade and call this exactly what it is:

The Parity team has shown they are incapable of production code without putting their user funds at risk. To date, they have put more effort into changing the Ethereum network to suit their project than toward building a beneficial product that is a boon to the ecosystem. Maybe Ethereum just isn’t the blockchain for the Partiy team? Maybe they should fork and start a chain that provides the FaaF they need?

Let’s not forget, the entire premise is the most recent Parity debacle is assuming the user ‘accidentally’ triggered the selfDestruct. The Developers left that feature in the code. The developers are responsible. Regardless, I would be willing to go on record (although it is not true) claiming to be the person who called selfDestruct and I would claim that title saying I did it intentionally. That would defeat the entire foundation of the original EIP. At least, for Parity users.

3 Likes
20

I suggest you rethink this approach; to claim that you’re willing to lie to get what you want really doesn’t help your argument.

21

ETH Recovery has been a desired thing since before the Parity multisig issue. While the Parity multisig issue is the biggest single loss, there are a large number of other smaller losses that effect a large number of users. I like blockchains because they prevent institutionalized theft (e.g., Civil Forfeiture and Chargebacks, not because they enable me to shoot myself in the foot. What I am proposing is that we protect people from shooting themselves in the foot where we can, while continuing to defend against institutionalized theft. I almost left for ETC because I saw it as an instance of institutionalized theft (effectively a chargeback), and in the end my reasons for sticking with ETH had nothing to do with the to-recover or not-to-recover question. Should institutional theft become a pattern, I would likely leave Ethereum.

For me personally, I have a Shelling Fence that prevents this from being a slippery slope. It certainly feels like the disagreement is around whether or not a Shelling Fence exists.

22

You can call my views extreme, but I genuinely believe that over the long term “protecting people from shooting themselves in the foot” will lead to institutionalised theft, especially considering there’s no formalised boundary. EIP-999 might not be considered theft, but each time we accept one of these proposals to essentially undo a transaction, we’re taking another step towards a centralised government that gets to choose which transactions are valid and which are not. Each recovery will set another a precedent just like the DAO fork did (if the DAO fork never happened, we wouldn’t even be having this conversation). Long term, if we accept state changes like this Ethereum will slowly evolve towards a corruptible, tyrannical system over the decades to come. These views were expressed in the DAO fork debate in 2016 and they are still valid today.

Institutionalised theft exists because a small minority of people hold more power than the rest. Many people are attracted to cryptocurrency because of the absolute property rights, i.e. nobody can interfere with your transactions. The fundamental awesome-ness of Ethereum is that code executes exactly as written and there shouldn’t be exceptions to that for people who are exceptionally negligent. This EIP breaks the core functionality of Ethereum.

As harsh as it may sound, un-freezing ether is a form of theft. When balances become frozen, the value attached to those burnt ether are effectively distributed to the whole economy. In the same fashion as when you transfer ether to 0x0000, or when you set fire to $1 trillion. Redistributing value from the current ether holders is a form of inflationary theft in the same sense that quantitative easing and corporate bailouts are hidden thefts.

For those that want a quasi-centralised system where transactions can be undone, they should opt-in to a solution on the Ethereum application layer; these decisions shouldn’t be made at the protocol level. It’s clear from the volume of debate in this EIP-867 and EIP-999, the split sentiment on reddit and the results of the EIP-999 coinvote that many people are not interested in a system like this.

You might have a personal fence, but the greater community doesn’t. I think we need to determine where that fence is now and commit to holding that promise for the future of Ethereum. And I think that if and when we come to a consensus on that, it should only be applied to future state changes (i.e. EIP-999 should fail no matter what).

Out of curiosity, where is your fence?

23

My current shelling fence for what can be recovered are funds that meet the following requirements (includes a bit of redundancy for clarity):

  1. The funds can be proven (probabilistically to some target degree) to be inaccessible by anyone.
  2. The funds have a plausible/believable/provable story as to how they became frozen that must have a root cause of “human error”.
  3. The funds are not currently accessible by a human (either provably or probabilistically).
  4. The funds were not intentionally burned by someone (this includes an attacker or a devious smart contract author).

Recovery means sending the funds back to whomever or whatever would have had access to the funds were it not for the human error.

24

A team has already implemented a recovery eth contract similar to what has come out of this thread - completely separate from this work. I think we should merge the two or begin working on ways to support this project and the ecosystem further.


https://info.silverwire.io/

I think this is an opportunity and seems to be receiving some nice support.

25

This implies that your shelling fence can move (current vs. future). Not a fence at all!

26

More a feature than a problem, as it effectively counters the “tyranny of the minority”

27

It is like those concrete road blocks/dividers. They are technically moveable, but it takes a massive amount of energy to do so. This means that against normal day to day pressures, or even a car running into it, it is quite stable in it’s position. However, if someone makes a concerted effort to intentionally move the wall it can be done.

My shelling fence for this is sturdy enough that I’m not worried about accidentally moving it through the course of day to day governance decisions, but I acknowledge that in the future someone may make a very compelling argument for intentionally moving the fence, and in such a situation I recognize that I may be convinced to do so.

This serves the purpose of a shelling fence in that it protects me from the problem of vague boundaries that are difficult to describe clearly and may move over time on accident. However, it does not calcify me into a position that may no longer make sense in the future when new information becomes available.

3 Likes
28

Agreed.

What new information has become available since the early days of touting hard immutability as a key benefit of Ethereum? Those promoting immutability at the time surely understood that all programmable systems come with bugs, and that these would in turn cause unanticipated losses or gains. Nothing new.

It is clear that hard immutability won’t fly in the real world, but It’s hard to see how Ethereum can now convincingly change what has been so thoroughly beaten into the collective consciousness.

29

Hard Immutability permits systems of fiat to exist on layers above it.

The same is not true for fiat -> immutability.

If you require fiat, this project already provides you the ability to write your fiat in public code where others can voluntarily participate - or not.

That is the strong argument for the benefit of immutability to all cryptocurrency, not just Ethereum.

30

At what point does repeated expressions that this is not a good idea followed by defense by a single individual become “rough consensus”?

31

Part of the problem is that people use the word immutability when they really mean something else (something less well defined). Check out the post by @phiferd over in here, he does a good job of describing reality and you can see that immutability of the blockchain is well defined, but quite constrained. This definition still holds even if we do a recovery.

So I would say the new information is people gaining a better understanding of what immutability really means, and what Ethereum (or any blockchain) really is in terms of guarantees. Back during TheDAO fork I was one of the people shouting about immutability and slippery slopes, but since then I have spent a lot of time thinking about governance, blockchains, etc. and because of that my stance has changed (though I’m still anti DAO fork to some extent, but for more well defined reasons).

I can’t speak to what the people in the early days meant when they said “immutability”, but as you can see in the link above Ethereum has never been completely immutable (that just doesn’t make sense).

I recommend checking out the writeup I linked above (in this comment), and then restate what you mean by “immutability”. I suspect what you mean is not that you want immutability, but that you want constraints on the ways under which the rules are allowed to change in the future. If you truly want immutability of the rules then I would argue that is against the ethos of Ethereum, since it has long been known that Ethereum will continue to develop as a platform with PoS, Sharding, etc. and that all requires rule changes.

If what you want are constraints on what rule changes can occur, then I recommend dropping the “immutability” argument (it isn’t well defined) and instead argue for how you believe the rules should be constrained. It would also help to argue why you believe that the governance system is incapable of handling this sort of thing in an equitable way.

Never. :smile: Just because the loudest people believe A, does not mean A is the majority belief. I continue to participate in the discussion because people continue to misunderstand the reality of the situation. If it was just a matter of one group wanting some particular value and another group wanting a different value or the two groups having different predictions on how future humans will behave, then I would have stopped discussing quite a while ago. However, people keep showing up to the discussion with incorrect mental models of reality and that isn’t helping anyone, especially when they propagate that incorrect mental model to others.

Some people have correct mental models of reality and still disagree because goals don’t align or predictions differ. Discussion between these parties has died down a bit because each side has said their piece and there isn’t anything obvious we can do to resolve the differences other than “try one and see what happens” or “accept that we have different goals and fork”.

2 Likes
32

I think it’s very important to correct misconceptions, and I appreciate that you do this. Do you agree though that at some point the discussion should come to “rough consensus”? (Are the words “rough consensus” from EIP 1, or is that just what people call it?)

33

Personally, I’m not a fan of the Bitcoin model of “we only make changes to the rules when everyone agrees”. This leads to stagnation when the userbase has two sufficiently large competing groups. This lead to it taking years for Segwit/Blocksize and along the way there were many forks rather than just one. I am of the opinion that when your userbase reaches the point where there are two groups with incompatible goals then it is time to fork.

The problem, of course, is that in the current environment it isn’t possible to fork without one of the two branches getting an unfair advantage when it comes to user choice. Which fork gets the ETH ticker symbol, which fork does Vitalik support? Which fork do Geth and Parity have as the default code in the master branch of their respective GitHub repositories? Which fork is the default for new Geth/Parity users?

This is an unfortunate situation, but one that doesn’t have any obvious/immediate solutions. At the same time, not allowing the protocol to evolve is bad (IMO), and if you want the protocol to evolve then you must accept that changes to the rules must be made. This then requires the majority of people participating in a particular fork of Ethereum generally agree on (or are at least not willing to switch forks over) how the governance system for rule changes work. That all culminates in us being in the situation we are in, and likely forking over the matter (again, I don’t think this is bad, I think this is a healthy solution).

1 Like
34

Point well taken. Brand is a scarce resource and, like a shark, movement forward is necessary.

35

I agree, this is not the actual Bitcoin model. This is the model posed by organizations like Blockstream that want to cripple the fundamentals of cryptocurrency.

We provide you with the means to achieve your ends - hard fork. Make your own chain and compete to win users.

36

Technical consensus is not the same thing as majority belief. E.g. the majority might be technically wrong, or their objections non-technical. Over the course of discussions I’ve seen continual improvement of our understanding of this EIP and related EIPs and issues. I haven’t seen a killer technical objection yet. I have seen serious philosophical, economic, and political arguments for and against. These need to be technically informed, and the technology needs to be informed by the rest of the world, so it’s fine that they happen here. But in the end, the technical soundness of the proposal is what matters, and wherever I come down on the other issues, it still looks sound to me. If that becomes the consensus, then the place to argue the other issues moves on to whether to adopt particular ERPs.

1 Like