Immutability Enforcement Proposal (IMP)

[sandakersmann]

Provide a standardized response against proposals for bailouts on the offical Ethereum repositories.

[5chdn]

Does this include dust and state-clearing proposals like #158?

[sandakersmann]

It does. So we better make sure that gas prices are on the ball.

[5chdn]

The abstract refers state changes, no you use the term bailouts, please consider adding a short definition paragraph to the proposal to clarify what you are referring to.

[5chdn]

This needs some work, will there be some Github-Webhook-Oracle that triggers the proposals to be closed? In its current state, it reads more like you are trying to improve Github, not Ethereum.

[sandakersmann]

We only need a standard process for the maintainers to follow.

[5chdn]

I fail to find the actual response in this proposal.

[sandakersmann]

The response is to close down such pull requests.

[5chdn]

Thanks for your proposal, I added some first review comments!

[Arachnid]

If you want to change the process for handling EIPs, you need to submit a PR to EIP 1, not a new EIP.

[sandakersmann]

@Arachnid Thanks for the suggestion. Adding a sentence, to forbid merging of bailout proposals, to EIP 1 might be the correct path forward.

[sandakersmann]

@5chdn Added some changes based on your feedback :)

[AtLeastSignificant]

This is an unusable definition. The word "bailout" is defined as an act of giving financial assistance to a failing business or economy to save them from collapse. This is not what you're proposing with your definition.

"Different ways" is far to vague. By this definition, putting precompiles on low-order addresses is a "bailout" since it's a state change done through a hard fork that effects an account in a "different" way than other accounts.

[sandakersmann]

This is the definition for this EIP.

[aribo]

I would avoid altogether the term "bailout"

As @AtLeastSignificant says, the term has a specific meaning, a redefinition for the purpose of this EIP adds ambiguity. Also "different ways" makes the concept too vague and open to a wide interpretation & application. This is the core of the definition, like this it's unusable/difficult to apply.

Besides, "bailout" is too charged of a concept, especially in the Ethereum/Crypto environment.

[sandakersmann]

I prefer to call a spade a spade.

[AtLeastSignificant]

But you're doing the exact opposite of that. You're calling state changes a "bailout". The "through a hardfork" clause doesn't meany anything, and "that treat account holders in different ways" is also too vague to be usable.

I think you might rephrase to:

"The definition of bailouts in this EIP is protocol changes that recover lost, stolen, or otherwise inaccessible funds in ways outside the core functionality of the current protocol".

I still don't like the word "bailouts" just because you shouldn't use words with existing definitions that don't relate to what you're redefining the word to, but at least that definition is usable.

[sandakersmann]

I disagree.

[bwheeler96]

"bailout" isn't the worst conflation I've ever seen, but I agree we may be able to find a better word. On that note, let's all try and be nice and helpful. I'd suggest the phrase "ad hoc recovery", but we might be able to do even better.

[AtLeastSignificant]

@sandakersmann

Disagree with what? I think my suggested definition actually hits what it is you're concerned about. Is this what you disagree with?

Or are you disagreeing with the fact that bailout is a defined word, and your use of it is a bastardization of that existing definition?

I think @bwheeler96 suggestion of "ad hoc recovery" is better, but it's sort of redundant IMO. When would you ever have a recovery that isn't "ad hoc"?

If I were to come up with a term that accurately describes what I think @sandakersmann is getting to, I would use "protocol irregular state changes for fund recovery".

[sandakersmann]

Bush called torture for enhanced interrogation, but it was still torture.

[bwheeler96]

@AtLeastSignificant in my view an "ad hoc" recovery is a recovery that pertains to making unusual network changes for a specific misuse of Ethereum technology, whereas a recovery that isn't "ad hoc" might be something like fixing a bug in the EVM that caused loss of funds, in which case the recovery may be warranted and the fixing of a bug would not be ad hoc in nature. The latter being extremely unlikely and the former would ideally be impossible.

[AtLeastSignificant]

This is a bad assumption. The controversial-ness of an irregular state change can be measured with many different (imperfect) mechanisms like CarbonVote, miner signalling, etc. It would be a bad decisions to assert that anything is "always" controversial.

This EIP doesn't raise the barrier for bailouts, it raises the barrier for discussing what you consider to be "bailouts". If approved as intended, it would be nothing more than frivolous censorship of harmless discussion.

Opposition to irregular state changes should be voiced in a fair setting, which this proposal seeks to undermine.

[sandakersmann]

It is not censorship since it is not deleted or restricted in any way. It is just not merged.

[AtLeastSignificant]

How is refusal to merge on principle not arbitrary restriction?

[sandakersmann]

There are no restriction on freedom of speech.

[AtLeastSignificant]

I really don't think this EIP or the one it's clearly in response to have anything to do with freedom of speech.

[sandakersmann]

Finally something we agree on :)

[debris]

I believe that this proposal brings nothing to a discussion that happened in eip #867. So as my comments in this review. I usually restrain myself from commenting publicly, but this discussion is an incredible waste of time. I feel sorry about that. So many great things could've been built instead of talking

[debris]

Every transaction is a state change, so you probably wanted to say 'irregular state changes'. And define what is an 'irregular state change'.

[sandakersmann]

It says "through a hardfork" and regular transactions do not happen by hardforks.

[debris]

it's so good that ethereum is a centralized protocol defined and owned by a single organization

[sandakersmann]

The official Ethereum repositories are centralized, but the protocol is not.

[AtLeastSignificant]

How are the official Ethereum repos centralized?

[sandakersmann]

If you look at this repo you will understand why:

https://github.com/popcorn-official/popcorn-app

[AtLeastSignificant]

So DMCA takedowns are the problem? This isn't a centralization problem with Ethereum, it's a problem with with Github. Are you suggesting that we create a development platform on top of the protocol so that it too is decentralized? I don't see how this is relevant to this EIP.

I think what @debris was getting at with their comment is that "standardized response" is something very few people are interested in, and the argument about official Ethereum repos being on Github has practically nothing to do with this. It isn't comparable to popcorn-app IMO.

[sandakersmann]

I said that the protocol is decentralized and that's why people are wasting their time crying for bailouts.

[AtLeastSignificant]

As a decentralized protocol run by miners, individuals are perfectly allowed to request that the protocol be changed for whatever reason. If the reason is understood and accepted by the miners, the change will happen. Period. End of discussion. That's literally all there is to it.

If you don't want these things to happen, you need to have a way to voice your objections. In every other platform I can think of (centralized or otherwise), there are standards to how the conversation is conducted. This is what the ERP EIP tried to create (and failed partially due to poor implementation), and what your EIP here seeks to undermine or eliminate. It's literally counter-productive to your own goal.

[debris]

That's your opinion

[AtLeastSignificant]

While I agree with your sentiment, voicing opinions about the protocol isn't an invalid use of the EIP system. Critiquing one's use of EIPs like this, regardless of how we subjectively see them, would undermine more subjectively valid uses.

[debris]

@AtLeastSignificant you are absolutely right. I just believe, that justification should contain something more than just an opinion e.g.

• irregular state changes are likely to cause a network split, like it happened with the dao fork
• if a network split happens, we are likely to cause X ether to be lost due to transaction duplication
• my twitter poll shows that 20 % of users will move to ethereum classic, cause it's immutable

just anything

[sandakersmann]

So following basic ethics is not a justification?

[AtLeastSignificant]

What do "basic ethics" have to do with this? What basic ethical argument are you actually making?

[Arachnid]

Personally I have a "basic ethical" principle that redefining words to mean things most people don't understand them to mean in order to push your political agenda is unethical.

[sandakersmann]

Bailout is the most fitting word I can think of.

[debris]

Correct me if I'm wrong, but the whole idea of EIPs is to standardize protocol for the developers and maintainers of the implementations. This has nothing to do with it. And as a maintainer I will follow the protocol, but I will not allow anyone to standarize my responses.

[sandakersmann]

@debris

You are free to do whatever you want, but I'm also free to do all I can to fight against bailouts and corruption entering the Ethereum ecosystem.

When you unlock funds through bailouts you dilute all the other accounts that were prudent and didn't throw their money into unaudited contracts.

People need to learn and if they can't learn from other peoples mistakes, they must learn from their own. People must put on their big boys pants, take responsibility for their mistakes and stop crying for bailouts. This will lead to a lot less mistakes in the long run.

Another question is who will get bailed out. My guess is that the people close to capable devs will get bailouts, while average Joe will get nothing. Reminds me of all those people sitting close to the central banks collecting all that newly printed money.

[AtLeastSignificant]

@sandakersmann

I don't think anybody is trying to stop you from fighting against "bailouts" (as you've tried to define them). I think this shows a fundamental misunderstanding of the purpose of the ERP EIP, which wasn't to actually perform "bailouts", but to discuss them in a meaningful way. If you want to have a valid platform to dissent, you should support having a level playing field for discussion - which the ERP EIP was seeking to create.

Your points aren't against this platform, they are against "bailouts". Why are you opposing a platform using arguments that don't relate to it?

[sandakersmann]

@AtLeastSignificant I'm not against discussions on open pulls, but merging is a totally different ballgame.

[AtLeastSignificant]

@sandakersmann

Merging doesn't add them to the protocol. It's literally just a step in the process to distinguish between "rough draft" and "in a state where real discussion about the merit of the proposal can be had". I don't see how this is "a totally different ballgame", or really even what you're trying to imply with that statement.

If it's that merging appears to be confirmation of the contents of the EIP, then you are wrong. The conditions for merging are very clear, and nowhere in them does it suggest that merging is confirmation or agreement to the proposal.

If you think that merging is in-fact this, and the EIP editors are acting against the rules, you have a problem with the editors, not the process.

[sandakersmann]

@AtLeastSignificant

So you are not against merging this pull then?

[AtLeastSignificant]

@sandakersmann

I am opposed to merging it as-is because I think there are improvements to be had before the argument you're making can be clearly debated. I am not opposed to merging it on principle though. I think this is a valid concern that many people have. Not a majority, but enough that it warrants discussion.

I guess I could argue that the argument goes against the Ethereum Philosophy, but it doesn't seem like anybody can actually define what that means anymore so I won't hold that against this EIP.

[Arachnid]

So you are not against merging this pull then?

As I've already mentioned, this EIP would do absolutely nothing, since you can't amend the EIP process by writing another EIP like this. Given that, I can only assume your reason for continuing to pursue this is pointless political grandstanding - a waste of everyone's time.

[sandakersmann]

@Arachnid

Bailout proposals are a waste of everyone's time.

[Arachnid]

@sandakersmann Whether something else is a waste of time is totally irrelevant to the question of whether this EIP is.

[AtLeastSignificant]

@Arachnid this is a good point, but I wouldn't be so hasty to call this reaction pointless - even if it cannot lead to any actual change to the EIP process.

@sandakersmann "Bailouts" as you've defined them are definitely not a waste of time to discuss, and I believe the only meaningful way to stop them is on a fair standard platform where they can be proposed. I myself am proof that "everyone" doesn't agree with this statement.

[sandakersmann]

@AtLeastSignificant The standard platform that you are looking for is called the Internet. No need to force this into the official Ethereum repos.

[Arachnid]

@AtLeastSignificant this is a good point, but I wouldn't be so hasty to call this reaction pointless - even if it cannot lead to any actual change to the EIP process.

There's no EIP category for "grandstanding"; merging this as an EIP would accomplish exactly nothing.

[AtLeastSignificant]

@sandakersmann That is an intellectually dishonest position. I hope you know this, or else it shows a significant amount of ignorance about what the internet is and how it's used.

@Arachnid fair enough. My point was more aimed at the fact that subjectively "bad" EIPs shouldn't be not merged if they are otherwise compliant with the merge standards.

[sandakersmann]

@AtLeastSignificant

I had a personal website up and running over 20 years ago. So I know a thing or two about how the Internet works.

[AtLeastSignificant]

@sandakersmann

Honestly, running a personal website doesn't mean you know anything about the internet at all -especially from the perspective of using it as a platform for meaningful discussion. I think this is pretty evident by how this discussion has devolved into what it is now, if it wasn't already at this level to begin with.

[sandakersmann]

@AtLeastSignificant

What do you expect when you are advocating for bailouts and corruption?

[AtLeastSignificant]

And with that, I think we can safely ignore both this EIP (since it literally cannot have a meaningful impact on the process) and @sandakersmann, since neither seem to be providing meaningful discussion.

Good luck, I'm out.

[maciejhirsz]

@sandakersmann

When you unlock funds through bailouts you dilute all the other accounts that were prudent and didn't throw their money into unaudited contracts.

I have a problem with this statement as it seems to reverse the logic here. I don't think the accounts that didn't "throw their money into unaudited contracts" where being prudent, they just didn't need to put their money into a contract at all. It is not obvious to me that should they have such a need, their ability to do due diligence on the contracts would be sufficient. On the flip side, it is obvious to me that people who had their funds increase in value due to someone else's misfortune are now incentivized to not fix the mistake, but that does not make them right.

Imagine such a scenario: you find a wallet on the street, there is an ID inside it that makes the owner easily trackable, and couple hundred bucks. Now imagine how weird it would be if instead of returning the money, you sent the owner a note saying that you hope they have learned their lesson about not losing wallets, and that you are not going to return the funds because it will be a financial loss to you.

[Arachnid]

This is a courtesy notice to let you know that the format for EIPs has been modified slightly. If you want your draft merged, you will need to make some small changes to how your EIP is formatted:

• Frontmatter is now contained between lines with only a triple dash ('---')
• Headers in the frontmatter are now lowercase.

If your PR is editing an existing EIP rather than creating a new one, this has already been done for you, and you need only rebase your PR.

In addition, a continuous build has been setup, which will check your PR against the rules for EIP formatting automatically once you update your PR. This build ensures all required headers are present, as well as performing a number of other checks.

Please rebase your PR against the latest master, and edit your PR to use the above format for frontmatter. For convenience, here's a sample header you can copy and adapt:

---
eip: <num>
title: <title>
author: <author>
type: [Standards Track|Informational|Meta]
category: [Core|Networking|Interface|ERC] (for type: Standards Track only)
status: Draft
created: <date>
---

[sandakersmann]

@Arachnid So why is this not merged when all the toxic bailout proposals are?

[Arachnid]

@sandakersmann Because as I pointed out way back in February, you can't amend the EIP handling process by writing a new EIP - you would need to propose a modification to EIP 1, instead.

[MicahZoltu]

Also the choice of wording in this EIP is not clear enough to allow a reader to make an informed decision as to whether they support the proposed changes or not. You can see the confusion in the dialog, where there isn't agreement on where the line is for what constitutes a "bailout".

[sandakersmann]

@MicahZoltu What constitutes a bailout is perfectly described in the definition.

[MicahZoltu]

The comment from Greg I think encapsulates the problems well: #894 (comment)

At the moment, the editors are not confident that the current draft provides clear enough guidance for a future reader to be able to take action based on the EIP text alone. One way this could be improved is to better defined what it means to "treat account holders differently". As previously discussed, this is different from "treat addresses differently" but that just makes it even more unclear since it is not possible to identify unique account holders (see Sybil attacks). Most of the proposed EIPs that this presumably argues against treats account holders equally (for some definition of equally), but applies different state transitions to different accounts (addresses). Cleaning up old accounts (with 0 ETH in them) is a great example of a state transition that treats all accounts equally (for some definition), but it is unclear from the text if this would qualify as "treating account holders differently".

I'm also personally not a fan of EIPs that use language that redefines existing words with preexisting connotative meaning to mean something different/new, especially when that connotative meaning is well known to be emotive. I continue to advocate changing the choice of wording from bailout to something more neutral, though if there are editors that are OK with redefining words and/or using emotive text in an EIP I probably wouldn't push back too hard on a merge if that was the only concern.

[fulldecent]

@MicahZoltu You have provided much feedback here. Please list under what conditions you would support this initiative. And then please explicitly state that you would support this initiative if those conditions were met.

[MicahZoltu]

Note: I'm not an EIP editor so I'm not the one you have to convince. 😄

I'm still not entirely clear on what the exact subset of EIPs @sandakersmann wants to auto-reject are, so I'm not comfortable making direct suggestions. What I would like is to be able to read this EIP and walk away with a very clear picture of what types of EIPs are allowed and what aren't. At the moment, this feels like a "EIPs aren't allowed, no more hard forks" EIP, since PoS is a hard fork that will have different levels of impact on different classes of users. Is this EIP advocating that we drop PoS as a target? If not, then more clarity is necessary. If it is, then I still think more clarity is necessary because I don't believe the casual reader will get that from the current text.

Secondarily, as has been stated numerous times in the past, this should be a pull request against EIP1. Unfortunately we don't have a great process for deciding how things get merged into EIP1 so I'm not actually sure how to go about it. Perhaps the right path would be to change this PR into an EIP that defines how EIP1 should be change (e.g., propose EIP1 changes and arguments for those changes) but don't actually touch EIP1. That way we can merge this as a draft without having to first agree on whether the governance process should change.

[fulldecent]

Understood, you're not an editor. You are a person with an argument and so you are not a useless person. The import question is:

If specification if "bailout" is tightened, will you recommend this standard for merging? (Or way of accepting this text as a "technically implementable" change)

If your answer to this question 👆 is NO then you have opaque reasoning. Opaque reasoning delays discussion of important matters and, to be frank, wastes everyones time. Opaque reasoning is a polite way of saying "ulterior motives".

Sure this EIP should be a PR against EIP1. The fact that it should be done one way does not make it ineligible to do another way. The Ethereum Recovery Proposal should be a PR against EIP1 as well for the same exact reasons.

---

You complain that the current definition of "bailout" is unclear. However here is a very brief review of other EIPS that were recently merged and which have unclear specification:

• http://eips.ethereum.org/EIPS/eip-1013 has a switchover block number of "TBD". "TBD" is not a number. EIP1 does not have any language mentioning "TBD" or the EIP author choosing a fork block number.
• http://eips.ethereum.org/EIPS/eip-1011 HYBRID_CASPER_FORK_BLKNUM is "TBD"
• http://eips.ethereum.org/EIPS/eip-908 has no specification whatsoever but only recommends things that should be studied (you wrote this)

I find the language in your accepted draft:

The user agent would contain the information needed to send an amount of ETH to the full node operator and the client developer orgnanisation, which are addresses held by these parties and the amounts to add.

as less specific than:

The definition of bailouts in this EIP is state changes to the Ethereum blockchain, through a hardfork, that treat account holders in different ways.

Sure, these can both be improved, THAT"S WHY IT"S CALLED A DRAFT.

[sandakersmann]

@MicahZoltu Proof-of-Stake is not state changes to the Ethereum blockchain, through a hardfork, that treat account holders in different ways. This should be obvious to most.

@fulldecent Indeed. These people are biased and ulterior motives are certainly a part of it.

[Arachnid]

Sure this EIP should be a PR against EIP1. The fact that it should be done one way does not make it ineligible to do another way.

Yes it does. You can't amend the process by writing a new EIP instead of amending EIP 1.

The Ethereum Recovery Proposal should be a PR against EIP1 as well for the same exact reasons.

That EIP does not propose to amend the EIP acceptance process, so there's no reason it would be an amendment to EIP 1.

[MicahZoltu]

@fulldecent The TBD block numbers are there because we won't know what block number the next fork is until it is planned. They are a way of saying, "include in some future fork" and is standard practice throghout EIPs. They will be updated with the fork block number once it is known and the code is written.

I agree with you, #908 shouldn't have been merged. In fact, I don't even think that should have been opened as an EIP but instead should have just been a GitHub issue or a discussion over at ethereum-magicians.

I would be happy to re-assess this EIP once it is made to be more clear. I'm hesitant to assert that "I'll 100% accept it once that definition is changed" because at the moment it is hard to assess the EIP overall when it is ill defined. I do not want people to feel like the EIP merging process is biased/unfair, and I believe the EIP maintainers want that as well. Despite any opinions I have as to whether this EIP is a good idea, I care more about the process being fair and reasonable. There is also still the problem that this is a change in process, which doesn't follow the "change in consensus rules" process for change control.

---

@sandakersmann While I appreciate that you feel like certain things "should be obvious to most", it turns out (as seen in this discussion) what is "obvious" to people is not the same for everyone. This is why we ask for more clarity on definitions and using more commonly accepted language, so that all readers of the EIP interpret it the same way. Right now it can be interpreted in a number of different ways because it is too vague.

[fulldecent]

@MicahZoltu How about this one: 👇

If the specification of "bailout" is made adjudicatable, will you recommend this standard for merging? (Or other way of accepting this text into the EIP process)

and also:

If the specification of "bailout" is changed to "TBD", will you recommend this standard for merging? (Or other way of accepting this text into the EIP process)

[fulldecent]

@MicahZoltu Please answer the question:

If the specification of "bailout" is changed to "TBD", will you recommend this standard for merging? (Or other way of accepting this text into the EIP process)

---

To be clear: I am testing if your support of merging this draft is based on the reasons you have stated or if you instead have ulterior motives.

[MicahZoltu]

Probably not because it is proposing a change to the governance process, and the EIP process is not the proper process for changing the governance process. I believe the current recommendations for changing the governance process is to propose a PR against EIP1. Note: The process for changing the governance process is not well exercised, so I'm not sure if it is as smooth as the EIP process.

[fulldecent]

@MicahZoltu There is an parenthesized clause in that question. Maybe this way of asking is more clear:

If the definition of bailout is changed to TBD, then will you support an Ethereum-wide policy (an EIP, a PR to EIP1, whatever) that reads similar to the text of this EIP?

[AtLeastSignificant]

@fulldecent the intent of this EIP isn't the problem, it's the way in which it's being done. I have half a mind to do the PR to EIP 1 myself just so we can move on after it's merged.

[Arachnid]

To be clear - I personally have a problem with the intent as well. Political considerations should not be being injected into a standards-making process. But that aside, the problem remains that you can't amend EIP 1 by writing a new EIP like this.

[github-actions]

There has been no activity on this pull request 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.

[fulldecent]

This was a fun discussion here. But if the original author does not exhibit the stamina to negotiate past finish line then this effort can be abandoned and the issue closed.

[MicahZoltu]

@fulldecent Just so you know, when you comment on a PR flagged by the bot like that, it starts the bot's entire countdown over again. So now this PR will be left open for at least 2 more months. 😢 My recommendation/strategy on these is to wait for the bot to close the issue before leaving comments. 😄

[github-actions]

There has been no activity on this pull request 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]

This pull request 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.