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

Standardized Ethereum Recovery Proposals (ERPs) #867

Merged
merged 5 commits into from Apr 16, 2018

Conversation

@phiferd
Copy link
Contributor

phiferd commented Feb 2, 2018

Provide a standardized format for Ethereum Recovery Proposals (ERPs), which relate to recovery of certain classes of lost funds.

Closes #866

@@ -0,0 +1,195 @@
## Preamble

EIP: <to be assigned>

This comment has been minimized.

Copy link
@jamslevy

jamslevy Feb 2, 2018

867 is EIP number


EIP: <to be assigned>
Title: Standardized Ethereum Recovery Proposals
Author: Dan Phifer (dp@musiconomi.com), James Levy, Reuben Youngblom

This comment has been minimized.

@5chdn
Copy link
Contributor

5chdn left a comment

  • I think the meta EIP should be in EIPS/eip-867.md and the ERPs can go into a sub directory.
The State Change Object is a standard format that will be interpretable by all Ethereum clients.

It is a single JSON object containing the following fields:
- **erpId**: An string identifier for this ERP (likely the associated EIP number, e.g. “EIP-1234”). This will converted from ascii to a hex string, then added as extra data on the target block.

This comment has been minimized.

Copy link
@pirapira

pirapira Feb 2, 2018

Member

"A string identifier"

This comment has been minimized.

Copy link
@phiferd

phiferd Feb 3, 2018

Author Contributor

thanks. fixed


Once an ERP is published (via a pull request made to the EIP repository), the approval process begins. The author is encouraged to seek feedback from the following groups:

- People or organizations who are directly affected by the issue (e.g. entities who will be refunded or were associated with the original incident)

This comment has been minimized.

Copy link
@pirapira

pirapira Feb 2, 2018

Member

[comment not as an EIP editor] are people directly affected, when they claim their ETH would be diluted after an ERP?

This comment has been minimized.

Copy link
@phiferd

phiferd Feb 2, 2018

Author Contributor

No. That would be an indirect effect. That certainly does not mean they cannot provide substantive feedback on the ERP. The goal is not to eliminate discussion on the ERPs but to focus it on the relevant issues (i.e. proof of ownership and the quality of the supporting evidence) rather than "should the ERP process exist" -- that discussion can happen here.

For ERPs, I think the legal concept of "standing" might be a good guideline.

Once an ERP is published (via a pull request made to the EIP repository), the approval process begins. The author is encouraged to seek feedback from the following groups:

- People or organizations who are directly affected by the issue (e.g. entities who will be refunded or were associated with the original incident)
- People or organizations that have a demonstrable history within the Ethereum community that are unaffected by the issue but may serve as relatively impartial adjudicators

This comment has been minimized.

Copy link
@pirapira

pirapira Feb 2, 2018

Member

Who will be checking the qualifications of these people and organizations?

This comment has been minimized.

Copy link
@phiferd

phiferd Feb 2, 2018

Author Contributor

I recognize that this is a bit squishy, but I don't believe any simple metric will accurately capture the intent. ERP authors and the people that express their support will need to make a significant effort in convincing others that there is support from both affected and unaffected. Note that the input expected from the unaffected parties is specifically around the quality of the supporting evidence (i.e. "does the ERP provide sufficient evidence for the specific claims").



## ERP Approval Process
Approval of any ERP will require a mandatory minimum of 30-days between the time the ERP is submitted (or substantially modified) and adoption by clients, and ERPs affecting more funds or more addresses may prompt a considerably longer review period. In practice, ERPs will often require more time because the will likely be bundled into other client upgrades that are on their own schedule. However, the 30-day mandatory review period guarantees a period for comment and auditing and prevents any last minute inclusions from being rushed into an upcoming upgrade.

This comment has been minimized.

Copy link
@pirapira

pirapira Feb 2, 2018

Member

[comment not as an EIP editor] I would prefer another mandatory period between the acceptance of ERP and the enforcement of the ERP. This gives chance for people to fork away from Ethereum if they disagree.

This comment has been minimized.

Copy link
@phiferd

phiferd Feb 3, 2018

Author Contributor

I don't think a separate period is necessary. The purpose of the ERP is to determine if the proof of ownership is clear, supported by convincing evidence. If some claim in the ERP is not well supported, people are free to comment, provide counter-evidence, or suggest what sort of proof might be more convincing.

However, if the ERP does provide strong evidence, no reasonable argument can be made counter to the original claim, and the affected parties are also in agreement about the outcome, I think providing another period where people can opt-out because they disagree with the facts that have been demonstrated to be true is counterproductive.


The ERP author may indicate in the ERP comments when he/she believes there is sufficient support and request a review by an EIP editor (see EIP-1 for details). The editor(s) will mark the ERP as “Accepted” or “Rejected”. As with any EIP, a Rejected ERP may be re-submitted upon substantial improvement.

Once an ERP is marked as “Accepted” by an EIP Editor, the block at which the changes will be applied will be finalized based on coordination between the client teams and other pending releases. Once the block is determined, a finalized version (updated to include the determined block) of the State Change Object will be published to the ERP. Clients will bundle this final version (unmodified) with their respective applications.

This comment has been minimized.

Copy link
@pirapira

pirapira Feb 2, 2018

Member

What prevents the EIP Editor from being sued for marking/not marking "Accepted"?

This comment has been minimized.

Copy link
@pirapira

pirapira Feb 2, 2018

Member

I guess, for this to work, all Ethereum users need to sign a document, saying, they will be following the decisions taken in the ERP approving process, no?

This comment has been minimized.

Copy link
@phiferd

phiferd Feb 3, 2018

Author Contributor

What prevents the EIP Editor from being sued for marking/not marking "Accepted"?

Certainly, even without this EIP, no one can claim that "no EIP Editor can ever be sued for anything". In fact, I would be hard-pressed to fill in the blank in "no can ever be sued for anything."

However, according to EIP-1 "The editors don't pass judgment on EIPs. We merely do the administrative & editorial part." This would apply to ERPs as well. Editors should expect ERPs to provide clear and convincing evidence as well as explicit feedback from others in the community (the second group mentioned) to indicate that they also find the evidence clear and convincing.

Keep in mind that the ERP process does not apply to cases where there is a reasonable disagreement between directly affected parties. It is not about determining "guilt" or "innocence" or making a value judgment. It is specifically meant to addresses cases where ownership is clear (similar to #156 )

I guess, for this to work, all Ethereum users need to sign a document, saying, they will be following the decisions taken in the ERP approving process

I don't think so, but I am not a lawyer. Do all Ethereum users sign anything right now?

@pirapira

This comment has been minimized.

Copy link
Member

pirapira commented Feb 2, 2018

This EIP puts more work on the EIP editors' shoulders. So if I may, how can I, as an EIP editor, put myself out of a bribable position?

Saying "I won't review ERPs until my concerns are resolved" is not enough because people can bribe me to disregard my concerns.

This leaves only a few options.

## ERP Approval Process
Approval of any ERP will require a mandatory minimum of 30-days between the time the ERP is submitted (or substantially modified) and adoption by clients, and ERPs affecting more funds or more addresses may prompt a considerably longer review period. In practice, ERPs will often require more time because the will likely be bundled into other client upgrades that are on their own schedule. However, the 30-day mandatory review period guarantees a period for comment and auditing and prevents any last minute inclusions from being rushed into an upcoming upgrade.

Once an ERP is published (via a pull request made to the EIP repository), the approval process begins. The author is encouraged to seek feedback from the following groups:

This comment has been minimized.

Copy link
@pirapira

pirapira Feb 2, 2018

Member

[comment not as an EIP editor] Why does this EIP specify these two groups? Why shouldn't all Ethereum users be heard?

This comment has been minimized.

Copy link
@phiferd

phiferd Feb 3, 2018

Author Contributor

This guideline states the minimum requirements that ERP authors must meet. Other people can (and should!) contribute to the discussion with substantive feedback relevant to the specific claims. i.e. to verify or dispute the facts presented with supporting evidence. Non-substantive feedback (e.g. "these guys are idiots" or some emoji) are of little value and can be easily manipulated.

Cases that fall under the ERP process are specifically ones that are factual in nature and can be handled through a process more closely resembling peer-review than a voting process. Recovery cases that are not factual in nature (i.e. where ownership cannot be proved) are intentionally not covered.

@phiferd

This comment has been minimized.

Copy link
Contributor Author

phiferd commented Feb 3, 2018

This EIP puts more work on the EIP editors' shoulders. So if I may, how can I, as an EIP editor, put myself out of a bribable position? Saying "I won't review ERPs until my concerns are resolved" is not enough because people can bribe me to disregard my concerns.

I suppose that is true of any EIP (e.g. I can submit an EIP to send 10% of all transfers to my account and then attempt to bribe people to get it through). However, the open nature of the process should prevent such attempts.

The evidence for an ERP is presented plainly in an open forum; decisions will not be made in secret.
Approval from an EIP Editor alone is not sufficient, nor is a lack of negative feedback. The ERP process explicitly requires "positive, explicit, and broad support" for the two groups of people listed as well as convincing evidence on proof of ownership. It is the responsibility of the community, in general, to point out when a particular action or proposal does not meet the requirements agreed upon in this meta-EIP.

If the amount of work required is an issue specifically (rather than bribery), we may be able to address that in a different way.

## Specification
This EIP describes a common format to be used for a subclass of EIPs, referred to as ethereum recovery proposals (ERPs), that propose an irregular state change required to address a fund recovery scenario that cannot be addressed using the standard protocol. Each ERP will reference this EIP will follow the guidelines set out here.

The purpose of each ERP is (a) to clearly describe the issue to be corrected, (b) to describe why an irregular state change is both necessary and justified, and (c) to demonstrate that the specific set of actions proposed achieve the ERP’s objectives.

This comment has been minimized.

Copy link
@pirapira

pirapira Feb 3, 2018

Member

"proposed to achieve"

This comment has been minimized.

Copy link
@phiferd

phiferd Feb 3, 2018

Author Contributor

I will reword -- it was meant to read as "(c) to demonstrate that [the specific set of actions proposed] achieve the ERP's objectives. Will change to "(c) to demonstrate that the proposed actions will achieve the ERP's objectives" for clarity


- **Preamble**: EIP (RFC 822) header containing metadata about the ERP, including the EIP number, a short title with a description of the issue (75 character maximum), and the real names (and optional contact information) for each author.
- **Simple Summary**: A simplified and layman-accessible explanation of the ERP.
- **Detailed description**: A human readable description of the the proposed corrective actions and the criteria used to determine the proposed actions.

This comment has been minimized.

Copy link
@pirapira

pirapira Feb 3, 2018

Member

duplicate "the" in "the the proposed corrective actions"


Positive, explicit, and broad support from both groups will be critical to the approval process; a lack of negative feedback is not sufficient. It is the sole responsibility of the ERP author and affected parties to find support. Feedback that is not substantive should be dismissed, and feedback for the ERP process as a whole should be directed to the this meta-EIP. Community members in general are encouraged to reference these guidelines to ensure the process remains focused, objective, and expedient.

The ERP author may indicate in the ERP comments when he/she believes there is sufficient support and request a review by an EIP editor (see EIP-1 for details). The editor(s) will mark the ERP as “Accepted” or “Rejected”. As with any EIP, a Rejected ERP may be re-submitted upon substantial improvement.

This comment has been minimized.

Copy link
@pirapira

pirapira Feb 3, 2018

Member

I think this line puts additional tasks of deciding "Accepted" or "Rejected" on EIP editors. So far, the EIP editors were able to leave an EIP as a "Draft" effectively forever. "Rejected" is for "after all is said and done".

An EIP can also be “Rejected”. Perhaps after all is said and done it was not a good idea. It is still important to have a record of this fact.

This comment has been minimized.

Copy link
@pirapira

pirapira Feb 3, 2018

Member

This doesn't prevent a merge of this PR as a draft. The affected parties should be consulted before this EIP becomes "Active".

This comment has been minimized.

Copy link
@phiferd

phiferd Feb 3, 2018

Author Contributor

To be clear, there are no "affected parties" related to this EIP. At least, not in the same sense as an ERP.

It just defines the process and recommends an implementation approach.

This comment has been minimized.

Copy link
@pirapira

pirapira Feb 5, 2018

Member

The proposal hears from directly affected parties, so, before this proposal becomes effective, the parties not listed in the ERP process need to be consulted.

@pirapira
Copy link
Member

pirapira left a comment

Looks good to merge as a draft.

@pirapira
Copy link
Member

pirapira left a comment

Or not.

My final cast of doubt is on the mention of

People or organizations that have a demonstrable history within the Ethereum community

, if this concept is up to the Ethereum philosophy or not. Let me ask in the next coredev meeting.

"not in keeping with the Ethereum philosophy" is one of the reasons for not merging.

@phiferd

This comment has been minimized.

Copy link
Contributor Author

phiferd commented Feb 3, 2018

Ok, maybe there's a better way to handle it. My goal was to ensure that there is some disinterested party to help give an objective opinion that can be verified by others in the community. Otherwise, people can get their friend/brother/neighbor to claim everything looks good. Or, they could just create a new GitHub account and pretend to be someone else.

@phiferd

This comment has been minimized.

Copy link
Contributor Author

phiferd commented Feb 3, 2018

Actually, how are the EIP editors chosen? Seems like the criteria would be the same as I suggested for ERP reviewers, except they it don't have to be the same group of people for each.

In any case, I'm open to other possibilities for that part.

@jamslevy

This comment has been minimized.

Copy link

jamslevy commented Feb 3, 2018

Maybe instead of this:

People or organizations that have a demonstrable history within the Ethereum community

It could be rephrased as:

People or organizations that have a demonstrable history of keeping with the Ethereum philosophy

The intention is to require not that the participants are community insiders, but that they have an understanding and respect for the network and its principles.

@phiferd

This comment has been minimized.

Copy link
Contributor Author

phiferd commented Feb 4, 2018

Agreed that "insiders" was certainly not intended.

However, I think there is some level of technical understanding required to validate the claims made in the ERP. Again, I see this as a sort of "peer-review", which requires that the "peer" is at least knowledgeable enough about the domain to understand the claims and evidence.

@pirapira
Copy link
Member

pirapira left a comment

The authors are still looking for a certain class of people who can make judgments. They are looking for authorities. This proposal dictates that the authorities' judgments to be implemented in Ethereum clients (currently, no rules dictate that client implementors should follow Accepted EIPs).

I think this proposal is at odds with the Ethereum philosophy. Single points of failure and the need of trust are what Ethereum tries to avoid. So, I cannot grant EIP status to this proposal, for not being "in keeping with the Ethereum philosophy."

You might wonder if the existence of EIP editors are against the Ethereum philosophy. Ideally, nodes would run their custom Ethereum client and protocol changes would appear from chaotic communication pattern without a centrepoint like this repository.

Currently this EIP repository exists, which is not ideal. Still, client implementors are free to implement/not implement changes. EIPs become "accepted" effectively only when they are agreed in a coredev meeting. So the EIPs' status are just following client implementors' decisions (this proposal reverses the direction, client implementors are supposed to follow EIP status marking, which I think is not acceptable). Sometimes a client changes its behavior but corresponding EIPs are missing. I like these cases where protocol consensus appears without central coordination.

The solution method is divided into three parts:

1. Standards that will need to be met by any follow-on ERP in order to be considered for approval.
2. Recommendations for a common format for ERPs to use to specify a set corrective actions that can be interpreted by clients.

This comment has been minimized.

Copy link
@5chdn

5chdn Feb 4, 2018

Contributor

a set of corrective actions



## Motivation
The issue of fund recovery on the Ethereum blockchain is often controversial. Frozen fund recovery proposals are almost never successful due to the relatively ad-hoc nature of such requests and the subjectivity that is often required to evaluate the merits. This EIP attempts to remove these barriers by providing both a standardized format for fund recovery EIPs, and an objective standard by which to measure future proposals.

This comment has been minimized.

Copy link
@5chdn

5chdn Feb 4, 2018

Contributor

fund recovery EIPS , and an


- **Preamble**: EIP (RFC 822) header containing metadata about the ERP, including the EIP number, a short title with a description of the issue (75 character maximum), and the real names (and optional contact information) for each author.
- **Simple Summary**: A simplified and layman-accessible explanation of the ERP.
- **Detailed description**: A human readable description of the proposed corrective actions and the criteria used to determine the proposed actions.

This comment has been minimized.

Copy link
@5chdn

5chdn Feb 4, 2018

Contributor

human-readable description

- **Simple Summary**: A simplified and layman-accessible explanation of the ERP.
- **Detailed description**: A human readable description of the proposed corrective actions and the criteria used to determine the proposed actions.
- **Justification**: A concise description of why the corrective actions are both reasonable and unlikely to be challenged by any directly affected party.
- **Verification script**: A machine readable script that outputs one State Change Object. The script should clearly implement the selection and action generating logic outlined in the description such that reviewers can independently re-generate an identical State Change Object .

This comment has been minimized.

Copy link
@5chdn

5chdn Feb 4, 2018

Contributor
  • machine-readable script
  • State Change Object _ .
- **State Change Object**: The output of the verification script and the input to the ethereum clients. Primarily, it specifies the complete set of proposed state change actions.
- **Appendix (optional)**: with supporting evidence. Attachments in the appendix may include documents verifying details specified as part of the recovery proposal description.

Once an ERP is approved (see **ERP Approval Process** section), clients (geth, parity, cpp-ethereum, etc) will apply the corrections at a specified block by directly reading and interpreting the State Change Object file.

This comment has been minimized.

Copy link
@5chdn

5chdn Feb 4, 2018

Contributor

etc.)

// continue with normal block processing...
```

The `applyRecoveryActions` method must apply the recovery actions in the same order as they are stored in the SCO file. Client are responsible for ensuring that no State Change Action will result in an account transferring an amount that is greater than its current balance. The `toAddress` for both `weiTransfer` and `storeCode` should always be a valid address (i.e. never `0x0`).

This comment has been minimized.

Copy link
@5chdn

5chdn Feb 4, 2018

Contributor
  • Clients are
  • (i.e. , never

The `applyRecoveryActions` method must apply the recovery actions in the same order as they are stored in the SCO file. Client are responsible for ensuring that no State Change Action will result in an account transferring an amount that is greater than its current balance. The `toAddress` for both `weiTransfer` and `storeCode` should always be a valid address (i.e. never `0x0`).

Additionally, each block affected by an ERP should include extra data to indicate that the state change occurred. The extra data included in the block should be the erpId found in the SCO file, converted to hex (i.e. `hexStringToBytes(asciiToHex(erpId))`). Clients should also validate that the expected header appears in the target block if the block is received from a peer.

This comment has been minimized.

Copy link
@5chdn

5chdn Feb 4, 2018

Contributor

(i.e. ,



## When to Write an ERP
Before writing a new ERP, please review the ERPs that have already been written (draft, approved, and rejected) to determine if your recovery case is potentially covered already by an open ERP. Even if it isn’t, similarities with other ERPs may help you to write a more effective ERP of find other people and organizations affected by your issue. A single ERP for cases that have a common cause and solution will be more likely to find support than many smaller ERPs. With that said, ERPs should be narrowly focused on a specific issue; combining cases that are unrelated into a single ERP will result in rejection.

This comment has been minimized.

Copy link
@5chdn

5chdn Feb 4, 2018

Contributor
  • a more effective ERP or find other
  • that are unrelated to a single ERP

## ERP Examples

This section will include examples and SCO resource files, as well as a brief tutorial for how to test using a private testnet.

This comment has been minimized.

Copy link
@5chdn

5chdn Feb 4, 2018

Contributor

tutorial on how to

Before writing a new ERP, please review the ERPs that have already been written (draft, approved, and rejected) to determine if your recovery case is potentially covered already by an open ERP. Even if it isn’t, similarities with other ERPs may help you to write a more effective ERP of find other people and organizations affected by your issue. A single ERP for cases that have a common cause and solution will be more likely to find support than many smaller ERPs. With that said, ERPs should be narrowly focused on a specific issue; combining cases that are unrelated into a single ERP will result in rejection.

## Implementation
A reference implementation has been written for the EthereumJ platform

This comment has been minimized.

Copy link
@5chdn

5chdn Feb 4, 2018

Contributor

I would link the PR here for reference. The links below might break in future.

(Hint: pressing Y on a specific Github page generates permanent links.)

- **type** (*string*): `weiTransfer`
- **fromAddress** (*hex string*): The address from which each should be transferred
- **toAddress** (*hex string*): The address to which eth should be sent
- **value** (*decimal string*): The amount to be transferred, in units of wei. The value must be a whole number and non-negative.

This comment has been minimized.

Copy link
@5chdn

5chdn Feb 4, 2018

Contributor

non-negative greater than 0.

@phiferd

This comment has been minimized.

Copy link
Contributor Author

phiferd commented Feb 4, 2018

The authors are still looking for a certain class of people who can make judgments.

No. The authors are looking for a class of people that are qualified to confirm that a claim is factual (not to make value judgments). It is peer-review, which does not require authority. However, it is meaningless if the "peers" that review the claims are not qualified to understand the subject matter. To be clear, anyone is free to provide evidence that either confirms or contradicts the evidence provided by the ERP authors. This is what was meant by "substantive feedback". The rationale for requiring some reviewers with a demonstrable history in the community was put forth as a minimum requirement to ensure some level of quality without requiring EIP editors or client teams to do all of the legwork. I can remove this part if it's problematic, but it still seems this EIP should at least encourage ERP authors to present such support.

I think this proposal is at odds with the Ethereum philosophy. Single points of failure and the need of trust are what Ethereum tries to avoid. So, I cannot grant EIP status to this proposal, for not being "in keeping with the Ethereum philosophy." You might wonder if the existence of EIP editors are against the Ethereum philosophy ... Currently this EIP repository exists, which is not ideal.

I'm not sure I follow this line of reasoning. First, are you saying that the EIP process itself is "not in keeping with the Ethereum philosophy"? Second, where is the single point of failure and need to trust? Agreed these are not desirable attributes, but I fail to see how it applies.

So the EIPs' status are just following client implementors' decisions

Really? I thought the proposal would be marked as "Accepted" after discussion and agreement between client teams (i.e. at core-dev meetings). Don't the EIPs typically drive those discussions? It seems like you're saying EIPs are just capturing what clients have already done. Is that true? If so, is there some other place to propose changes to client teams? From EIP-1: Once an EIP has been accepted, the implementations must be completed.

this proposal reverses the direction, client implementors are supposed to follow EIP status marking, which I think is not acceptable

The intent was not to assert control over client teams -- if there is somewhere in the proposal where acceptance of the ERP is implied to be compulsory, I will remove it. This meta-EIP is a recommendation for a process that could be adopted by the community as a standard/norm which would improve quality and reduce risk associated with a certain class of proposals. In the event that a client team does not want to accept an ERP, there is obviously no way to compel them to accept it (nor have we proposed one). However, I would expect that this intention would be made clear during the ERP review process and their reasons would be clearly stated.

Ideally, nodes would run their custom Ethereum client and protocol changes would appear from chaotic communication pattern without a centrepoint like this repository.

We should be very careful to recognize the fundamental difference between coordination and control. Most decentralized systems do not aim to remove coordination, they aim to remove the authority to compel; the very fact that coordination can be achieved without control underpins the entire decentralized philosophy. This repository (and many other open source repositories) are points of coordination, not control.

@jamslevy

This comment has been minimized.

Copy link

jamslevy commented Feb 4, 2018

The concern @pirapira raises about bribery is good, and there is not one silver bullet but there are multiple things that can be done together to minimize the risk of corruption. As @phiferd points out this EIP is primarily aimed at standardizing a coordination process, without prescribing certain details regarding how coordination takes place as it is considered to be out of scope from what is largely a technical format and process described by this EIP.

Here are some things that can minimize the possibility of successful corruption:

  1. A minimum review period. Currently, the minimum period is 30 days ("Approval of any ERP will require a mandatory minimum of 30-days between the time the ERP is submitted (or substantially modified) and adoption by clients") but if the feedback indicates that this is not enough time, it could be increased. In practice, the review period would almost always be much longer than 30 days so it's not likely to change anything if it were increased to something like 90 days or more.

  2. More requirements about the number of reviews that must take place or specifications regarding the bonafides of the reviewers. In my opinion it would be a mistake to halt the process of reviewing the technical elements of this EIP until the details of reviewer coordination are determined, especially because these details are likely to evolve and adapt to the feedback and ideas of core developers, and evolve organically as the process is tested.

  3. Other measures that haven't been proposed yet - if anything, we are very eager for suggestions and feedback of this nature.

Also, it is worth noting that while ERPs are an obvious area with potential for corruption, there are many types of EIPs - such as block difficulty adjustments, for example - that also are vulnerable to corruption. Governance of a decentralized system is truly difficult!

@phiferd

This comment has been minimized.

Copy link
Contributor Author

phiferd commented Feb 5, 2018

Is this the sentence you are referring to @pirapira ?

Once an ERP is marked as “Accepted” by an EIP Editor, the block at which the changes will be applied will be finalized based on coordination between the client teams and other pending releases.

I have rephrased to:

Once an ERP meets the minimum requirements and client teams have indicated their intention to include the ERP as part of some future upgrade, the block at which the changes will be applied will be finalized and the ERP will be marked as "Accepted". The target block will be determined based on coordination between the client teams and other pending releases.

@Arachnid

This comment has been minimized.

Copy link
Collaborator

Arachnid commented Mar 13, 2018

@eth-button What seems wrong to me about this whole thing is the talk at the EthCC session about pushing community consensus all the way to the edge, where the choice is reduced to "fork or not", where "fork" includes this change in addition to many others.

If you disagree, why didn't you chime in? Rough consensus only works if people raise their objections.

I also agree with some of the arguments here that take the approach of proving a contradiction. If we assume that "community consensus" is a pre-requisite for a change to be implemented, we can also assume that it's a requirement for that same change to be adopted. This implies that if there is no community support for a change, it can never be adopted. If the change cannot be adopted, moving it to "draft", even on technical merit alone, is an exercise in futility and a waste of everyone's time.

That implies you have some way to assess community consensus accurately, and know what it is. If you do, please let the rest of us know too!

Not having an opinion outside of the technical aspects of an EIP also doesn't seem like a valid excuse. Someone can come up with any number of technically sound but morally/socially/ethically damaging proposals, such as a standardized means of blacklisting addresses, for example. It should be obvious that, while entirely technically feasible, such a proposal is fundamentally opposed to the "censorship-resistant" nature of the blockchain, and should be rejected outright. Even if the proposal itself is technically sound and no technical grounds for rejection can be found, it seems obvious that such a proposal would still be rejected outright, before even considering the technical aspect.

Those proposals should absolutely be merged - and then not implemented if they're bad ideas.

Any other option politicises the standardisation process. This has several unwanted effects:

  • It mixes together technical and political concerns, making it harder to clearly argue either one.
  • It breaks the consensus-based system of standardisation, which relies on being able to objectively assess proposals and objections. Political positions are much more subjective and aren't susceptible to the same process.
  • It creates an environment in which some technically sound ideas can't be discussed. If this persists, it encourages the creation of a parallel standards process that doesn't have these constraints, fracturing the technical community.

It's worth stating once again that the EIP process is not a governance process, it's a standardisation process - and an input to the governance process. There is nothing that says all changes to the chain must occur through an EIP; that's just the easiest and standard way to do so. Trying to make EIPs into a political system would simply result in technical discussion migrating elsewhere.

@haseebawan

This comment has been minimized.

Copy link

haseebawan commented Mar 13, 2018

If i sold ETH two years as a mistake, would I get them back as well if I return the BTC I received from them?So Basically the proposal is that we should have a set of individuals who will decide who lost the money and who didn't. What kind of stupid proposal is it ?

@kayagoban

This comment has been minimized.

Copy link

kayagoban commented Mar 13, 2018

@davidhq

This comment has been minimized.

Copy link

davidhq commented Mar 13, 2018

@kayagoban not everyone can see that, two options:

  • they have direct interest because they screwed up big time, now want to be saved without regards to the community or the health of a platform (or even society at large)

  • they don't understand enough about core philosophy of this space which is not supposed to work like messy politics of the current world... which is falling apart and can potentially only be saved with something what Ethereum was supposed to become if it succeeds

@kayagoban

This comment has been minimized.

Copy link

kayagoban commented Mar 13, 2018

@bernardpeh

This comment has been minimized.

Copy link

bernardpeh commented Mar 13, 2018

just to clarify the eip process. if this eip is merge, does it go into "draft" or "accepted" mode?

based on the guidelines,

Draft - an EIP that is open for consideration

Accepted - an EIP that is planned for immediate adoption, i.e. expected to be included in the next hard fork (for Core/Consensus layer EIPs).
@jamesray1

This comment has been minimized.

Copy link
Contributor

jamesray1 commented Mar 13, 2018

@bernardpeh it would be a draft. It can't be included in a hard fork, as it doesn't propose any state changes.

@jstoxrocky

This comment has been minimized.

Copy link

jstoxrocky commented Mar 13, 2018

@kayagoban

A helpful thing to focus on would be to make sure that this change becomes a standalone fork that miner clients would need to opt in to, not a client default or part of a protocol upgrade.

Like @MicahZoltu said, at the end of the day we all have veto power by choosing to run/not run whatever software we want. That being said, clients like geth may be so popular that if they make a change, it may act as a strong enough "coordination flag" as to prompt other clients to adopt the same change. In fact, #191 seems to have been slightly born out of geth forging ahead on their own. This issue is compounded by the fact that many do not run their own nodes, placing more "coordination" power in the hands of whatever client is running on Infura nodes etc.

One solution might be to somehow level the client playing field in order to reduce the "coordination" power that specific clients have. Not sure how to do this other than grass-roots forking of repos and trying to get others to run your software that "promises" to never recover any ERP funds.

@charles-cooper

This comment has been minimized.

Copy link
Contributor

charles-cooper commented Mar 13, 2018

@jstoxrocky and @MicahZoltu to take the idea of leveling the client playing field further I would like to float the idea of setting aside a portion of block rewards and/or transaction fees towards a development fund. That way ether holders and ether users (collectively, stakeholders) have a clear path towards funding client development wherein the developers will be financially aligned with the funders as opposed to the current regime where client teams may - or may not be - aligned with stakeholders. I'm not saying that the current client teams are doing a bad job, but that stakeholders should have at least some representation in the development process.

For the purpose of establishing representation for the different groups, perhaps the development funds generated from block rewards (which represent coin holders) should be segregated from the development funds generated from transaction fees (which represent coin users).

Also I would like to point out again that while this meta-EIP is technically feasible, having ERPs go through the EIP system seems counter to EIP-1 which states among other things that "An EIP is a design document providing information to the Ethereum community, or describing a new feature for Ethereum or its processes or environment" - which ERPs are not. So in order to strictly follow the process, EIP-1 would need to be modified before any ERP could even be accepted. But perhaps what I am gathering from the comments in this thread from EIP editors is that that discussion around the non-technical merits of this EIP can only happen after it has been merged in "Draft" form.

@jamslevy

This comment has been minimized.

Copy link

jamslevy commented Mar 14, 2018

@charles-cooper deriving client development funding from block rewards is an interesting idea but the tricky part is determining the parameters for this that would be as fair as possible. Let's say for example that 1% of block rewards are used for this fund. How would this then be split among various projects? It could be simply weighted according to usage but then the large, mature incumbent client projects would get the most backing, and some would argue that this would be unfair.

@charles-cooper

This comment has been minimized.

Copy link
Contributor

charles-cooper commented Mar 14, 2018

@jamslevy therein lies the rub!

I think that some sort of carbon voting mechanism could be implemented where a user can specify where they would like their 'portion' of the funds directed towards. This makes it much less of an 'all-or-nothing' deal where users either get stuck with some big compromise that nobody really wanted or a majority inflicts their will on the minority. (Note: I think this is technically easier to track for block rewards and harder to track for txn fees, especially if users use multiple addresses - but ultimately technically possible for both cases).

I imagine there could be N listed projects (with the barrier-to-entry of listing very low), and users can elect which projects their portion of taxes/fees goes towards. If there is no election, the default is that the reward gets burned or goes to miners. An analogy with taxation would be like the bureaus publish their funding 'wishlist' and taxpayers collectively set the budget.

@phiferd

This comment has been minimized.

Copy link
Contributor Author

phiferd commented Mar 14, 2018

@charles-cooper check out https://ethereum-magicians.org/ and start a topic there. I think your idea will otherwise get lost in this thread.

@charles-cooper

This comment has been minimized.

Copy link
Contributor

charles-cooper commented Mar 14, 2018

Thanks @phiferd! Is that now the de facto incubating area for discussing governance proposals?

@Arachnid

This comment has been minimized.

Copy link
Collaborator

Arachnid 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>
---
@jamesray1
Copy link
Contributor

jamesray1 left a comment

I just want to make it clear that the reason that I approved this EIP is because it is technically sound. That does not necessarily mean that I agree with it. There are many pros and cons to it. People make mistakes and perhaps they should deserve to have some kind of way to recover funds for making a small mistake, or if a developer makes a mistake (or it is hacked, or a user makes a mistake, etc.) while many others are affected. Then again, maybe people get what they deserve if they make a mistake, where the more negligent they are, the more they may deserve it. It is a very philosophical thing to make a call on; who has the authority to make such a decision; should we even give any such person or collective of people such authority! (Even a blockchain-powered democracy or voluntary rough-consensus-driven technical committee.) Personally I would not be inclined to place absolute faith in anyone, without having absolute faith myself!

OTOH, it increases the bureacratic burden on Ethereum which adds costs. Then again, those costs may be smaller compared to the cost of recovering funds, but then again, they may not, if the funds are simply unrecoverable, and new Ether has to be issued. This bureaucracy also increases centralization (or at least risks it, even if it can be counteracted through a DAO). There is also an opportunity cost of dedicating resources to techno-bureacratic fund recovery. Perhaps funds could be recovered, minus costs incurred from recovering them. The amount of stuck and stolen funds seems small compared to the total velocity of Ether, even if it is still a relatively large absolute amount. So it is hard to tell whether the proposal is worth it. But it is OK to merge as a draft.

@phiferd phiferd force-pushed the Musiconomi:erp branch from 94fc1bc to 9bedcbb Apr 4, 2018

type: Meta
status: Draft
created: 2018-02-02
replaces: 156

This comment has been minimized.

Copy link
@5chdn

5chdn Apr 4, 2018

Contributor

Apparently, this causes tests to fail, so since EIP-156 was never merged, you should remove it.

- ./_site/EIPS/eip-867.html
  *  internally linking to eip-156, which does not exist (line 55)
     <a href="eip-156">156</a>
htmlproofer 3.8.0 | Error:  HTML-Proofer found 1 failure!

phiferd added some commits Apr 5, 2018

phiferd and others added some commits Apr 16, 2018

@Arachnid Arachnid merged commit 668f1f5 into ethereum:master Apr 16, 2018

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@Arachnid

This comment has been minimized.

Copy link
Collaborator

Arachnid commented Apr 16, 2018

I've merged this PR to create a draft EIP, as it meets all the requirements for an EIP editor to do so. Because I know this will be contentious, I'd like to highlight a few important points:

  • Merging as a draft does not imply approval. Anyone can write an EIP, and as long as it's well formatted and meets a very low bar of soundness, an EIP editor will merge it as a draft.
  • This does not mean the EIP is accepted, or that it will be part of a hard fork. That decision is taken at All Core Devs, and ultimately the acceptance or otherwise of a hard fork is up to the userbase, not the EIP editors. The editors will update the state of an EIP to reflect decisions made at all core devs and the state of the chain, not the other way around.
  • This is the beginning of the conversation about this EIP, not the end. To avoid fragmenting conversation in multiple venues, please take discussions about the EIP itself to the discussions-to URL, here.
@postables

This comment has been minimized.

Copy link

postables commented Apr 20, 2018

@jamslevy why do you keep bringing this up? Hasn't the community said no enough already? Is 2 times not enough? Have you not learned from your mistake that instead of asking for the entire Ethereum community to make up for your mistakes and the mistakes of everyone involved who lost money because you all didn't do your own due diligence and looked at the code you used? This is absolutely ridiculous that you keep submitting this exact same thing over and over and over again. Just stop it already for fucks sake. Smart contracts and the Blockchain are designed for immutability. If you can't take a few days to audit the code you use than you're a fool and deserve anything and everything that happens as a result of your misuse

@jamslevy

This comment has been minimized.

Copy link

jamslevy commented Apr 22, 2018

@postables I personally do not have any funds affected by the Parity case or otherwise frozen due to a lack of audited smart contract code. Also, EIP 867 makes an explicit point of not advocating for any particular case of frozen funds. Finally it is recommended to discuss at https://ethereum-magicians.org/t/eip-867-standardized-ethereum-recovery-proposals-erps/139

Arachnid added a commit to Arachnid/EIPs that referenced this pull request May 2, 2018

Standardized Ethereum Recovery Proposals (ERPs) (ethereum#867)
* * Trying to fix issues from rebase

* * Removing reference to EIP-156

* * Adding discussions-to header
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.