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.

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

Immutability Enforcement Proposal (IMP) #894

Open
wants to merge 3 commits into
base: master
from

Conversation

@sandakersmann
Copy link
Contributor

commented Feb 21, 2018

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



## Abstract
Proposals that advocate for any state changes to the Ethereum blockchain should not be merged into the official Ethereum repositories.

This comment has been minimized.

Copy link
@5chdn

5chdn Feb 21, 2018

Contributor

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

This comment has been minimized.

Copy link
@sandakersmann

sandakersmann Feb 21, 2018

Author Contributor

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



## Motivation
The issue of bailouts on the Ethereum blockchain is always controversial. This EIP attempts to raise the barriers for bailouts.

This comment has been minimized.

Copy link
@5chdn

5chdn Feb 21, 2018

Contributor

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.



## Specification
If a pull request is opened that advocates for bailouts or implements code that can result in state changes on the Ethereum blockchain, it will be closed.

This comment has been minimized.

Copy link
@5chdn

5chdn Feb 21, 2018

Contributor

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.

This comment has been minimized.

Copy link
@sandakersmann

sandakersmann Feb 21, 2018

Author Contributor

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



## Rationale
The primary consideration for the approach described above was to reject all bailouts. A secondary consideration was to standardize the response to such pull requests.

This comment has been minimized.

Copy link
@5chdn

5chdn Feb 21, 2018

Contributor

I fail to find the actual response in this proposal.

This comment has been minimized.

Copy link
@sandakersmann

sandakersmann Feb 21, 2018

Author Contributor

The response is to close down such pull requests.

@5chdn

This comment has been minimized.

Copy link
Contributor

commented Feb 21, 2018

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

@Arachnid

This comment has been minimized.

Copy link
Collaborator

commented Feb 21, 2018

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

@sandakersmann

This comment has been minimized.

Copy link
Contributor Author

commented Feb 21, 2018

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

@sandakersmann

This comment has been minimized.

Copy link
Contributor Author

commented Feb 21, 2018

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



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

This comment has been minimized.

Copy link
@AtLeastSignificant

AtLeastSignificant Feb 21, 2018

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.

This comment has been minimized.

Copy link
@sandakersmann

sandakersmann Feb 21, 2018

Author Contributor

This is the definition for this EIP.

This comment has been minimized.

Copy link
@aribo

aribo Feb 21, 2018

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.

This comment has been minimized.

Copy link
@sandakersmann

sandakersmann Feb 22, 2018

Author Contributor

I prefer to call a spade a spade.

This comment has been minimized.

Copy link
@AtLeastSignificant

AtLeastSignificant Feb 22, 2018

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.

This comment has been minimized.

Copy link
@sandakersmann

sandakersmann Feb 22, 2018

Author Contributor

I disagree.

This comment has been minimized.

Copy link
@bwheeler96

bwheeler96 Feb 22, 2018

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

This comment has been minimized.

Copy link
@AtLeastSignificant

AtLeastSignificant Feb 22, 2018

@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".

This comment has been minimized.

Copy link
@sandakersmann

sandakersmann Feb 22, 2018

Author Contributor

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

This comment has been minimized.

Copy link
@bwheeler96

bwheeler96 Feb 22, 2018

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



## Motivation
The issue of bailouts on the Ethereum blockchain is always controversial. This EIP attempts to raise the barriers for bailouts.

This comment has been minimized.

Copy link
@AtLeastSignificant

AtLeastSignificant Feb 21, 2018

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.

This comment has been minimized.

Copy link
@sandakersmann

sandakersmann Feb 21, 2018

Author Contributor

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

This comment has been minimized.

Copy link
@AtLeastSignificant

AtLeastSignificant Feb 21, 2018

How is refusal to merge on principle not arbitrary restriction?

This comment has been minimized.

Copy link
@sandakersmann

sandakersmann Feb 22, 2018

Author Contributor

There are no restriction on freedom of speech.

This comment has been minimized.

Copy link
@AtLeastSignificant

AtLeastSignificant Feb 22, 2018

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

This comment has been minimized.

Copy link
@sandakersmann

sandakersmann Feb 22, 2018

Author Contributor

Finally something we agree on :)

@debris
Copy link

left a comment

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



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

This comment has been minimized.

Copy link
@debris

debris Feb 21, 2018

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

This comment has been minimized.

Copy link
@sandakersmann

sandakersmann Feb 22, 2018

Author Contributor

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

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

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

This comment has been minimized.

Copy link
@debris

debris Feb 21, 2018

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

This comment has been minimized.

Copy link
@sandakersmann

sandakersmann Feb 22, 2018

Author Contributor

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

This comment has been minimized.

Copy link
@AtLeastSignificant

AtLeastSignificant Feb 22, 2018

How are the official Ethereum repos centralized?

This comment has been minimized.

Copy link
@sandakersmann

sandakersmann Feb 22, 2018

Author Contributor

If you look at this repo you will understand why:

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

This comment has been minimized.

Copy link
@AtLeastSignificant

AtLeastSignificant Feb 22, 2018

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.

This comment has been minimized.

Copy link
@sandakersmann

sandakersmann Feb 22, 2018

Author Contributor

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

This comment has been minimized.

Copy link
@AtLeastSignificant

AtLeastSignificant Feb 22, 2018

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.



## Justification
Bailouts play favorites with some accounts on the Ethereum blockchain. This is corruption we can not tolerate in the offical Ethereum repositories.

This comment has been minimized.

Copy link
@debris

debris Feb 21, 2018

That's your opinion

This comment has been minimized.

Copy link
@AtLeastSignificant

AtLeastSignificant Feb 21, 2018

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.

This comment has been minimized.

Copy link
@debris

debris Feb 21, 2018

@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 :trollface:

just anything

This comment has been minimized.

Copy link
@sandakersmann

sandakersmann Feb 22, 2018

Author Contributor

So following basic ethics is not a justification?

This comment has been minimized.

Copy link
@AtLeastSignificant

AtLeastSignificant Feb 22, 2018

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

This comment has been minimized.

Copy link
@Arachnid

Arachnid Feb 23, 2018

Collaborator

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.

This comment has been minimized.

Copy link
@sandakersmann

sandakersmann Feb 23, 2018

Author Contributor

Bailout is the most fitting word I can think of.

@debris

This comment has been minimized.

Copy link

commented Feb 21, 2018

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

This comment has been minimized.

Copy link
Contributor Author

commented Feb 22, 2018

@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

This comment has been minimized.

Copy link

commented Feb 22, 2018

@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

This comment has been minimized.

Copy link
Contributor Author

commented Feb 22, 2018

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

@AtLeastSignificant

This comment has been minimized.

Copy link

commented Feb 22, 2018

@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

This comment has been minimized.

Copy link
Contributor Author

commented Feb 22, 2018

@AtLeastSignificant

So you are not against merging this pull then?

@AtLeastSignificant

This comment has been minimized.

Copy link

commented Feb 22, 2018

@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

This comment has been minimized.

Copy link
Collaborator

commented Feb 22, 2018

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

This comment has been minimized.

Copy link
Contributor Author

commented Feb 22, 2018

@Arachnid

Bailout proposals are a waste of everyone's time.

@Arachnid

This comment has been minimized.

Copy link
Collaborator

commented Feb 22, 2018

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

@AtLeastSignificant

This comment has been minimized.

Copy link

commented Feb 22, 2018

@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

This comment has been minimized.

Copy link
Contributor Author

commented Feb 22, 2018

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

@Arachnid

This comment has been minimized.

Copy link
Collaborator

commented Feb 22, 2018

@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

This comment has been minimized.

Copy link

commented Feb 22, 2018

@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

This comment has been minimized.

Copy link
Contributor Author

commented Feb 22, 2018

@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

This comment has been minimized.

Copy link

commented Feb 22, 2018

@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

This comment has been minimized.

Copy link
Contributor Author

commented Feb 22, 2018

@AtLeastSignificant

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

@AtLeastSignificant

This comment has been minimized.

Copy link

commented Feb 22, 2018

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

This comment has been minimized.

Copy link

commented Feb 22, 2018

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

@fulldecent

This comment has been minimized.

Copy link
Contributor

commented Feb 27, 2018

Regarding humans. The yellow paper states:

"... it is assumed that the ultimate external actor will be human..."

Regarding "Human beings are unaffected by implementation details." You are correct, my language was imprecise. The better wording "human beings insofar as they are account holders and not programmers" fizzles all remaining arguments.

But also, you left out the most important question: If the standard were updated to match my premises as per above, and if my logic is valid, and if the EIP is technically sound, then would you still reject this EIP on the basis that you want more The DAO hardforks (and against the founding basis that technically sound EIPs should be accepted)?

@AtLeastSignificant

This comment has been minimized.

Copy link

commented Feb 27, 2018

Digging back far enough in this thread, I say

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.

Assuming I want more of any hardfork is unwise.

Those who truly want to avoid ERPs should be in support of things like EIP 867 that would give them a valid platform to reject such proposals, not trying to make the conversation about it needlessly harder than it could be. You won't stop ERP discussion, so supporting a fair standard where both side can have rational discourse is the only good option as far as I can tell.

Carefully notice that I say "like EIP 867", I am not suggesting that EIP is any better than this one.

@AtLeastSignificant

This comment has been minimized.

Copy link

commented Feb 28, 2018

Also, you conveniently leave out a pretty important piece of context to that quote @fulldecent.

In full:

A transaction (formally, T) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. While it is assumed that the ultimate external actor will be human in nature, software tools will be used in its construction and dissemination1.

1 Notably, such ‘tools’ could ultimately become so causally removed from their human-based initiation—or humans may become so causally-neutral—that there could be a point at which they rightly be considered autonomous agents. e.g. contracts may offer bounties to humans for being sent transactions to initiate their execution.

I think this makes it abundantly clear that the assumption is for practical reasons, not something that is expected to be 100% true. It also carries the caveat that this assumption will likely not even be a practical one as the tools for constructing and disseminating transactions become autonomous.

This argument that "an account holder is a human" is very quickly defeated by the fact that I have automated scripts that generate and sign transactions without my interaction. That script shares ownership with me because we both know the private keys, and it is certainly the more active entity.

@fulldecent

This comment has been minimized.

Copy link
Contributor

commented Feb 28, 2018

You have automated scripts that generate and sign transactions.

Insofar as those scripts generate and sign transactions, are those generating and signing activities in any way whatsoever affected by whether the network tracks their account balances on the blockchain or on the /dev/null filesystem?

@Arachnid

This comment has been minimized.

Copy link
Collaborator

commented Mar 1, 2018

If you are only concerned with "account holders" being treated differently, then you should be in agreement with a hard fork that recovers funds sent to typo addresses, or those generated by the js bug, correct? In both those cases, all account holders will have all funds from typoed/miscalculated versions of their address swept into their address.

@fulldecent

This comment has been minimized.

Copy link
Contributor

commented Mar 1, 2018

Rewording from @Arachnid:

Strawman proposal: "any account, a, shall be able to retrieve funds held in account a ± 1." Would this strawman and others like it fall under jurisdiction of EIP-894?

No. It is reasonable to assume that a 255-bit hash is in the same class of birthday-attack resistance as a 256-bit hash. So we can reasonably assume that the a ± 1 account is not owned by anyone. On its face, this strawman does not meet the definition of a bailout and should not be closed on account of EIP-894. If further inspection makes clear (To who? The EIP editors.) that strawman actually is a bailout for some other reason then EIP-894 does oblige the EIP editors to follow the action in the specification section.

This answers part of your question. Sorry I am not familiar with a JS bug part.

@MicahZoltu

This comment has been minimized.

Copy link
Contributor

commented Mar 4, 2018

@fulldecent Based on the definition of bailout in this EIP, what Arachnid described is a bailout (it is a state change via hard fork that treats some accounts different from others). If you would like to change the definition of bailout I encourage you proposing as much, but as currently worded it would include the strawman Arachnid proposed.

@fulldecent

This comment has been minimized.

Copy link
Contributor

commented Mar 7, 2018

@MicahZoltu you are correct that accounts are treated differently.

However, bailouts do not concern accounts, they concern account holders. It can be reasonably assured that nobody holds those extra ±1 accounts. If I am wrong and those ±1 accounts are owned then yes it is a bailout.


This EIP is sufficiently descriptive of the problem and prescriptive on its solution.

It may be possible to add wording that includes some of the defense I have given. However, such would not change the substance of the EIP. Also, I do not see anybody here saying that they would support the EIP if I was a coauthor and included this wording in there. I suspect this is because some people fundamentally support the possibility of bailouts.

@MicahZoltu

This comment has been minimized.

Copy link
Contributor

commented Mar 7, 2018

If you support the ±1 recovery example that Arachnid mentioned then you are not in agreement with the author of this EIP, who is against that (and similar) proposal. This lack of clarity on what exactly this EIP attempts to do is why many of us are requesting more clear wording than "bailout".

@Arachnid

This comment has been minimized.

Copy link
Collaborator

commented Mar 27, 2018

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

This comment has been minimized.

Copy link
Contributor Author

commented Apr 17, 2018

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

@Arachnid

This comment has been minimized.

Copy link
Collaborator

commented Apr 17, 2018

@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

This comment has been minimized.

Copy link
Contributor

commented Apr 17, 2018

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

This comment has been minimized.

Copy link
Contributor Author

commented Apr 17, 2018

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

@MicahZoltu

This comment has been minimized.

Copy link
Contributor

commented Apr 17, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Apr 18, 2018

@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

This comment has been minimized.

Copy link
Contributor

commented Apr 18, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Apr 20, 2018

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:

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

This comment has been minimized.

Copy link
Contributor Author

commented Apr 20, 2018

@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

This comment has been minimized.

Copy link
Collaborator

commented Apr 20, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Apr 23, 2018

@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

This comment has been minimized.

Copy link
Contributor

commented Apr 23, 2018

@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

This comment has been minimized.

Copy link
Contributor

commented May 20, 2018

@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

This comment has been minimized.

Copy link
Contributor

commented May 21, 2018

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

This comment has been minimized.

Copy link
Contributor

commented May 21, 2018

@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

This comment has been minimized.

Copy link

commented May 21, 2018

@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

This comment has been minimized.

Copy link
Collaborator

commented May 22, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.