EIP 867: Standardized Ethereum Recovery Proposals #866
Comments
|
Here's the PR: #867 |
jaytoday
changed the title
|
Reopening for discussion (/issues/867 redirects to the pull request) |
jaytoday
changed the title
|
Here's the unintended consequence of having a readily available, well documented, and standardized tool like this available:
|
|
@fulldecent this would require massive coordination among people running clients to succeed, essentially like any other kind of 51% attack. And to further eliminate the possibility of such a thing occurring it would be possible to put in place certain hardcoded safeguards, mainly in the interest of stopping people from even attempting this sort of thing thinking it has any chance of working. One idea that has been floated is a checksum in the state change objects that would only be generated when a legitimate ERP process has been successfully approved. As one of the coauthors of the proposal, I can safely speak for all of us in saying we definitely don't want any possibility for this tool to be usable for taking people's money away from them. |
|
Since any given recovery proposal may result in an economic fork if implemented by clients, and the first one to be implemented undoubtedly will, an ERP should also specify an alternative network ID to minimize disruption. I'm not sure what the process would be for deciding which fork gets the existing network ID and which one uses the new ID, but I guess that's outside the scope of this EIP. |
|
IMHO, all changes should update the network ID. The baseline is no network ID change. Technically we would stop using the term "hard fork" and then call it "new version". Yes, this is version number bloat. Semver already provide ample support for bloating version numbers before making rather than making changes with the same version number. |
|
I think forking is easier, better and preferable to a bureaucratic process. As you point out, this proposal is just the Tyranny of the Majority
I can misunderstand too. But I see forking as the solution to immutable history if you disagree with the history. Furthermore, I think this fundamentally misunderstands the point of cryptocurrency. A major appeal, for me, is the push vs pull type of transaction. This breaks that. Because now the network has a pull transaction that can take money from anyone - just like banking. Then I don't technically own my coins. The people who can vote to take them do. I don't think I support this on any grounds but I can be educated if I am completely missing the point. |
|
Let me just make sure I understand what this is EIP is about; 'Let's standardize the way that we can react to any DAO-type events?' That's like asking 'let's create a process for using our get out of jail free card' ignoring the fact that you only get one get out of jail free card. If this EIP is implemented it's as good as saying 'yes we'll hard fork again to recover lost funds'. This kills the trustless nature of the chain. That kills the chain itself. There's no reason to have this EIP unless you want to initiate such recoveries. |
|
Given the community split around this EIP, and its potential for major damage, is it possible to have a wider RFC for the broader community? |
|
Personally, I cannot find words to express how strongly I am against this proposal, and many people from the Reddit community seem to share this opinion. I would strongly urge to somehow gather the opinion from the broader community on this topic before this is even considered. |
|
First, I'm sorry for your lost and all others who lost ETH in parity bug or others who had lost eth in the wild. Second, I am really scared by what I'm reading on this EIP(I'm a sysadmin so no blockchain/coder skilled guy). If I get this right, you are proposing a way to submit, let's use the right word, a request to revert transaction or refund ETH and that not only for a one time deal but as a standard process ? We should probably forget about Ethereum and use a spreadsheet so it could be easier to correct error ? Ethereum survived the DAO Fork and I think it was necessary at the time, but this, this is not what "we" are building. I don't think you'll get a lot of people on board with that kind of idea other than those who will benefit, indeed. I hope the community will speak it's word, even if you are not a technical person and you can at least understand the repercussion of this for the entire Ethereum project. Write a comment here with your thought, as Ethereum will grow more money will come in and "attack" like this to the immutability of the TX will happend, we need to standup and speak, either for or against but this is a crucial question. If 10 eth is stuck somewhere now, it's a 10kUSD lost you might live with it, but think about how many of those proposal we'll see if eth is worth 5k or 10k one day ? |
|
I am also against this proposal. An irregular state change should be by definition, irregular. This EIP is an attempt to standardize irregular state changes, making them regular state changes. There is no possible way everyone in the community will be able to read/digest/vote on all manual state-changes going forward if this EIP is accepted - reducing the decentralization of the platform. There should be no standard for making an irregular state-change. They should be so infrequent that none is needed. When a significant event does occur prompting calls for a reversion by the community there will be sufficient discussion already around the pros and cons of the choice. |
|
I have to agree with all the other users against this proposal. Issues like the ones this claims to "help" are the very thing we should not be standardising. These are exceptional issues and should only be considered when the community has a calling for it. Not when some "standard form" you fill out gets sent to some group and agreed on. I should also say, what happens with finality? If you plan to make a system where reversions are impossible after x blocks, how can this system work? You would have a set time to rush the request through a body in order to keep finality. |
|
I am 100% against this as a long-time eth miner and supporter |
|
This is nothing that should be on the Ethereum network. |
|
This proposal defeats the whole point of PoW/PoS. A network with users that accept that an "EIP Editor" can change balances at will could as well use that "EIP Editor" to order transactions. |
|
No matter how much we hate this proposal, please keep the discussion civil. While I agree with your sentiment, there are other words that can be used to express that opinion. |
|
@nootropicat @justbotrelatedthings This is not a place for profanity. If you can't keep it civil, don't say it |
|
100% opposed to this EIP it's very damaging to the future of Ethereum. |
I am curious as to how having EIP Editors could effect the centralization of the platform. Can anyone direct me to this |
|
I don't support this. This sort of things shouldn't be built into the blockchain. If people really want to see this sort of capability I recommend letting dApps or DAOs handle this. That way, people can opt in our out such provisions. |
|
Do not support this |
|
@brenthompson2: EIP-1 is available here. It deals with the format of EIPs. I'll chime in with the others here, and say I oppose this proposal. Standardizing the reversal of transactions on the blockchain cannot possibly end well, even moreso when a small group of people are relied on entirely to do so. |
|
@adamrabie eth classic is worth far, far less in terms of market cap and overall user adoption. Aside from that, that wasn't the point I was making with that statement, simply that a hard fork like that one could be applicable to a situation that was worth than the DAO event. I'm fully aware of my position on this subject, but thanks for playing |
|
@ngerrity sounds like you're gonna need a system like this for arbitrating your not so clear line at all about where refunds should or shouldn't happen. |
|
The system is already in place, how do you think that original hard fork happened before this EIP existed? Furthermore, in the thread linked at the top now, I reiterated my statement above and included a link to a comment by another person that proposed an opt in type of insurance for ico/users that could potentially be a better solution without changing what many believe to be a core principal of what ethereum and distributed ledgers in general stand for |
|
@ngerrity original fork happened informally by @vbuterin et al getting pulse on community decision and acting as 'benevolent dictators' in interpreting and implementing their perception of what was wanted. If you think that informal process is better, great, but it's an ERP system nonetheless, just without the fancy name and more clear procedure this offers comparatively, and a lot of trust in Vitalik per se. I'm surprised everyone here seems aware of the grey lines being drawn by this EIP and the dangerous slope it takes us down but miss the fact that the original fork inevitably brought us here. Ethereum has already compromised immutability in a major way, and that can of worms being cracked is now bearing fruit. And if immutability and proposals like this being DOA is desired other chains like bitcoin or eth classic maybe more appropriate for those with such desires. This EIP is totally within the spirit of how Ethereum usually addresses other issues like upgrades, and panic mode fork compromises of previously promised immutability. This is why i'm confused with people saying this proposal should be dead on arrival, when if you birds eye and look around, there is no more appropriate proposal for this community. Anyways would be cool for Ethereum to be immutable from now on but once you lost it its hard to get back. |
|
I'm on the ETC side for the immutability and the core values but I was wondering. Even if EIP 867 goes against some basic principles of decentralised technology, I believe that blockchain is still in a very early stage and we should test different kind of politics. ETC is the immutable side so why don't we let ETH try a different approach and let time be the judge of that ? The simple existence of ETC is a good way to put pressure on ETH for not abusing with EIP 867 and users will choose. Am I too naive ? |
|
On this ethereum chain there is not a question of "if" a hardfork to correct contract bugs can happen, but rather under what circumstances. We had a similar debate around the time of the DAO split and it's result was that those who wanted the chain to be an immutable ledger where "code is law and contracts operate as written without regard to intent" were allowed to exist as ETC. The understanding has always been that if some event were to happen on ETH again where a fork were necessary, it would happen in an open and transparent manner. Imagine if a flaw were discovered in erc20 for instance, is that fork worthy? Having a formal system in place is sane. It does not mean that it's use would be routine. In society we have rules and procedures in place for all manner of extraordinary events( nuclear missile launches ) This does not mean they are good and proper, only that their is a formal safety net in place . The DAO hack was a disaster only second to the chaos of the failed (unwanted) soft fork, ridiculous carbon vote, and fork by default patch that was put out. Having to repeat that situation is far worse than having a system in place for extraordinary circumstances |
|
@realcodywburns <- most sensible, honest Ethereum defender here. |
|
I understand and I respect that approach. I have another question in order to have a better opinion because for the moment, I have litterally no opinion on this. I don't have enough knowledge for that. Is EIP 867 a way for Ethereum to cover its back in case something goes wrong with the changes that are coming ? (Casper, PoW to PoS...) Beceause in that case, defining rules for EIP 867 seems a good idea to avoid future abuse. |
|
I understand immutability. However, I wish the people opposed to this measure would avoid hyperbole and state a real reason with a real world example of their dissent why this would be a world ending event. Just saying "No... can't do it... no way..." reminds me of oppressive religous nonsense..."No...women can't drive... no way.. it's law". Everyone robotically and vigorously opposes any change to the doctrine but why? We forked for the DAO and those investors got their money back. What if we didn't fork? Would those initial investors be as enthusiastic about Eth? Woud Eth be as popular or would be be where Eth classic is. Would I be sitting at #ethdenver right now? Would Eth even exist in it's current standing? IMHO if I was a Dao investor and had a few million stolen and the Eth foundation said to me.."Sorry. Immutability... hacker keeps your money" I would probably sue and never want to be involved in Eth again. That fork saved Eth. I'm not saying this is the same situation but we need to tread the line between unquestioning platform-centric zealotry and practical code management and development. Blockchain is not scripture. It's code... built by humans... It will change... It must change and adapt or we will be replaced by something more flexible to real world events. |
|
@Lietmotiv but nobody owes you anything, in both the case of getting your Eth back and in the case of meaningful discussion. Also, under what grounds would you have to sue an organization for? You didn't lose money, you lost Ethereum, in your example. Nobody has an obligation to keep your Ethereum safe for you. You need to do that for yourself before anyone else. |
|
@IceAmaura the hypothetic eth cost fiat. I guarantee if we played out the Dao hack without the hard fork it ends badly for ethereum. No one would risk capital on it going forward. Who would? I don't want to argue hypotheticals. We live in the real world with real world problems and solutions. Dogma is fine for guidance but rigidity and inflexibility due to dogma has never been qualities of a sustainable platform. Imaging if Microsoft stayed with the Windows NT kernel. It was secured and hardened over many years and was stable but they recognized that NT isn't going to work for the mass market. If they had forced everyone to live in that ecosystem someone else would have disrupted (and ultimately Apple did). Question your assumptions. A strong mighty tree will be destroyed by hurricane winds but the reed will bend with the wind. |
|
@Lietmotiv : I think that you're right about the DAO hack fork. Without it, ETH and ETC wouldn't be where they are. The context is different today. I understand you but I also understand the other side. They're defending a different kind of vision for Blockchain tech in general. It's not only about Ethereum. This is a complicated situation we're in but I think that opening this discussion is a very good thing for the evolution of Blockchain. I personnaly believe that having ETH with the EIP 867 and ETC with immutability is a good thing. It gives choice and I think both visions can exist together. It's just my opinion. |
|
@Lietmotiv there’s a difference between standardizing a process for ethereum recovery vs. doing a hard fork, as in the case of the DAO. In my opinion, the protocol and code are law, and introducing a human offchain procedure for reversing transactions can erode trust in the system. However, I think hard forks can be encouraged. If most people disagree with the protocol and/or state of the system, then they could fork. |
|
Feel like this thread is rampant with misunderstandings and an offical blog post outlining the specifics of this should be done to allow for formal and well informed debate and "vote". First, the EIP specifically states: First we are talking about instances of obvious error and no dispute. Second, the ERP states: Lets start here, if I understand correctly - we aren't (yet) debating IF there should be a process for fund recovery .. we are talking about creating a framework to determine if and how it should occur. So, its entirely plausible that we create the framework for which a recovery process could occur but decide that recovery of funds in general, as a consensuses of the community, is not desirable and will not be used. For example, the end result of the ERP could be that This is at least one possibility. is that right @jamslevy @phiferd ? As a side comment, if github comments are the medium to which we formally discuss and debate future proposals ... we are in deep trouble. |
|
That is correct @cardassian-tailor. This EIP just defines to framework for proposing recovery proposals. It does not propose any recovery itself and it does not guarantee that any recovery proposal will go through and be implemented my clients. |
|
Strongly oppose this. I was not happy about the DAO decision please don't make that mistake again. |
|
Completely opposed to this proposal. It makes ethereum fragile and pointless. It's either immutable or a waste of everyone's time. Choose one. |
|
This would set a dangerous precedent for smart contract programmers to think they have a rescue button. In general many programmers are lax on proper security to begin with, and this won't help. This type of thing should be handled by a community vote off chain, because it relates to emergency changes to the state. |
|
There is one more potential issues with it: Adopting this will create more incentives for people who think they can issue orders (courts, central banks,etc) to order modifications of blockchain. Whose orders must be followed and whose are to be ignored? All of them should be ignored? |
|
This doesn't even solve the problem, it multiplies the problem. This could bog down the system with endless bureaucracy. Coupling this concern to ETH could be significantly detrimental. Stay lean. -1 |
|
I discount that risk. To change the chain a Court, King, President, Dictator, or Satan would have to proceed just like everybody else and write an EIP. |
|
Comment moved to 867. |
|
ETH isn't decentralized in a way, that one foundation is in a whole process of code writing, so why are you opposing, when in fact ETH and it's consensus aren't decentralized, as DAO hack has shown. |
|
“Build unstoppable applications lol |
|
Is there a possibility to avoid this mess with a sidechain that audits smart contracts on the main chain ? A PoS sidechain that could be used to keep an eye on the main chain by registering main chain transactions on the sidechain, something like a RAID 1 hard drive configuration. That sidechain could have more supply than the main chain (around 10x the amount of ETH in circulation) and keep the equivalent amount of ETH for the main chain backup. Its supply could augement with the sidechains mining but a percentage of new coins could be preserved to keep up with ETHs inflation. I'm not sure I'm using the best way to explain but I think you can get the whole idea. We should try everything else before allowing human intervention. We have no idea of what future can bring and humanity has a talent in finding surprising ways to mess with justice. |
|
The rollback ability should be limited by time, say one day. The TX must be confirmed during that day, using confirmation smart-contract of payee's choice or predefined policy and if it's not confirmed, it should auto-rollback. The rollback should not require consensus to complete. The smart-contract of payee's choice may be used to send tx key it via push or email, or integrate via rpc, and then, some 2FA would return that call to commit the tx. Banks settlement procedures are time-tested. I do not understand why there's urge to reinvent the wheel if one wants solid flow. |
|
@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 |
|
Please take further discussion to https://ethereum-magicians.org/t/eip-867-standardized-ethereum-recovery-proposals-erps/139 |
and others
Please refer to #867
The text was updated successfully, but these errors were encountered: