Standardized Ethereum Recovery Proposals (ERPs) #867
Conversation
EIPS/eip-erps/eip-erps.md
Outdated
| @@ -0,0 +1,195 @@ | |||
| ## Preamble | |||
|
|
|||
| EIP: <to be assigned> | |||
EIPS/eip-erps/eip-erps.md
Outdated
|
|
||
| EIP: <to be assigned> | ||
| Title: Standardized Ethereum Recovery Proposals | ||
| Author: Dan Phifer (dp@musiconomi.com), James Levy, Reuben Youngblom |
There was a problem hiding this comment.
EIPS/eip-erps/eip-erps.md
Outdated
| 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. |
EIPS/eip-erps/eip-erps.md
Outdated
|
|
||
| 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) |
There was a problem hiding this comment.
[comment not as an EIP editor] are people directly affected, when they claim their ETH would be diluted after an ERP?
There was a problem hiding this comment.
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.
EIPS/eip-erps/eip-erps.md
Outdated
| 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 |
There was a problem hiding this comment.
Who will be checking the qualifications of these people and organizations?
There was a problem hiding this comment.
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").
EIPS/eip-erps/eip-erps.md
Outdated
|
|
||
|
|
||
| ## 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. |
There was a problem hiding this comment.
[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.
There was a problem hiding this comment.
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.
EIPS/eip-erps/eip-erps.md
Outdated
|
|
||
| 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. |
There was a problem hiding this comment.
What prevents the EIP Editor from being sued for marking/not marking "Accepted"?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
|
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. |
EIPS/eip-erps/eip-erps.md
Outdated
| ## 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: |
There was a problem hiding this comment.
[comment not as an EIP editor] Why does this EIP specify these two groups? Why shouldn't all Ethereum users be heard?
There was a problem hiding this comment.
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.
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. If the amount of work required is an issue specifically (rather than bribery), we may be able to address that in a different way. |
EIPS/eip-867.md
Outdated
| ## 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. |
There was a problem hiding this comment.
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
EIPS/eip-867.md
Outdated
|
|
||
| - **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. |
There was a problem hiding this comment.
duplicate "the" in "the the proposed corrective actions"
EIPS/eip-867.md
Outdated
|
|
||
| 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
This doesn't prevent a merge of this PR as a draft. The affected parties should be consulted before this EIP becomes "Active".
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this 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.
|
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. |
|
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. |
|
Maybe instead of this: It could be rephrased as: 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. |
|
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. |
There was a problem hiding this 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.
EIPS/eip-867.md
Outdated
| 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. |
EIPS/eip-867.md
Outdated
|
|
||
|
|
||
| ## 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. |
EIPS/eip-867.md
Outdated
|
|
||
| - **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. |
EIPS/eip-867.md
Outdated
| - **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 . |
There was a problem hiding this comment.
- machine-readable script
- State Change Object
_.
EIPS/eip-867.md
Outdated
| - **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. |
EIPS/eip-867.md
Outdated
| // 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`). |
EIPS/eip-867.md
Outdated
|
|
||
| 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. |
EIPS/eip-867.md
Outdated
|
|
||
|
|
||
| ## 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. |
There was a problem hiding this comment.
- a more effective ERP or find other
- that are unrelated to a single ERP
EIPS/eip-867.md
Outdated
|
|
||
| ## 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. |
EIPS/eip-867.md
Outdated
| 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 |
There was a problem hiding this comment.
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.)
EIPS/eip-867.md
Outdated
| - **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. |
There was a problem hiding this comment.
non-negative greater than 0.
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'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.
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:
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.
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. |
|
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:
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! |
|
Is this the sentence you are referring to @pirapira ?
I have rephrased to:
|
|
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 ? |
|
This EIP is has potential to create a seriously contentious hardfork if it gets packaged with a protocol upgrade. It seems almost a trojan horse whose intent is to wreck Ethereum’s upgrade path.
The DAO rescue was an agile departure from dogma that helped Ethereum survive its early years. Although I understand EF developers’ desire to adere strictly to EIP protocol, when that protocol is being used as an attack vector against the platform, another agile response is needed. The progress of this EIP needs to be stopped at some point, and I hope people can see that.
…Sent from my iPhone
On Mar 13, 2018, at 12:59 PM, haseebawan ***@***.***> wrote:
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 ?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@kayagoban not everyone can see that, two options:
|
|
@davidhq there’s no call to question the motives of devs who are trying to adhere to EIP protocol. The difficulty of this EIP is that it places them in a position where they feel they’re being asked to sacrifice established protocol to stop an EIP that they probably know is a bad idea.
Unfortunately, principled people who obey rules and social norms are sometimes used as exploits to do bad things. Try understanding their positions a bit. Cool heads prevail and reasonable people get listened to.
I believe this will be solved, if not here then at a later stage.
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.
…Sent from my iPhone
On Mar 13, 2018, at 3:18 PM, davidhq ***@***.***> wrote:
@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
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
just to clarify the eip process. if this eip is merge, does it go into "draft" or "accepted" mode? based on the guidelines, |
|
@bernardpeh it would be a draft. It can't be included in a hard fork, as it doesn't propose any state changes. |
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 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. |
|
@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. |
|
@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. |
|
@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. |
|
@charles-cooper check out https://ethereum-magicians.org/ and start a topic there. I think your idea will otherwise get lost in this thread. |
|
Thanks @phiferd! Is that now the de facto incubating area for discussing governance proposals? |
|
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:
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: |
There was a problem hiding this 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.
EIPS/eip-867.md
Outdated
| type: Meta | ||
| status: Draft | ||
| created: 2018-02-02 | ||
| replaces: 156 |
There was a problem hiding this comment.
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!
|
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:
|
|
@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 |
|
@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 |
* * Trying to fix issues from rebase * * Removing reference to EIP-156 * * Adding discussions-to header
EIP-1 is in the wrong table and no table exists for EIPs that are both Finalized and Active. Quoting the EIP: > Some Informational and Process EIPs may also have a status of “Active” if they are never meant to be completed. E.g. EIP 1 (this EIP). This can lead to confusion just like it happened [here](ethereum/EIPs#867 (comment)). To avoid that I am moving the EIP in the Readme to its own special table.
Provide a standardized format for Ethereum Recovery Proposals (ERPs), which relate to recovery of certain classes of lost funds.
Closes #866