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

EIP 867: Standardized Ethereum Recovery Proposals #866

Closed
jamslevy opened this Issue Feb 1, 2018 · 142 comments

Comments

Projects
None yet
@jamslevy

jamslevy commented Feb 1, 2018

Please refer to #867

@phiferd

This comment has been minimized.

Contributor

phiferd commented Feb 2, 2018

Here's the PR: #867

@jamslevy jamslevy closed this Feb 2, 2018

@jamslevy jamslevy changed the title from EIP 866: Standardizing Ethereum Recovery Proposals to EIP 867: Standardizing Ethereum Recovery Proposals Feb 2, 2018

@jamslevy

This comment has been minimized.

jamslevy commented Feb 2, 2018

Reopening for discussion (/issues/867 redirects to the pull request)

@jamslevy jamslevy reopened this Feb 2, 2018

@jamslevy jamslevy changed the title from EIP 867: Standardizing Ethereum Recovery Proposals to EIP 867: Standardized Ethereum Recovery Proposals Feb 3, 2018

@fulldecent

This comment has been minimized.

Contributor

fulldecent commented Feb 15, 2018

Here's the unintended consequence of having a readily available, well documented, and standardized tool like this available:

Donald Trump's Ethereum address is 0x34987109857123409734097497. You just have to click on this script to take his money away.

@jamslevy

This comment has been minimized.

jamslevy commented Feb 15, 2018

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

@edmundedgar

This comment has been minimized.

edmundedgar commented Feb 15, 2018

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.

@fulldecent

This comment has been minimized.

Contributor

fulldecent commented Feb 15, 2018

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.

@tenthirtyone

This comment has been minimized.

tenthirtyone commented Feb 15, 2018

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

this would require massive coordination among people running clients to succeed, essentially like any other kind of 51% attack.

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.

@Volodath

This comment has been minimized.

Volodath commented Feb 15, 2018

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.

@ryanberckmans

This comment has been minimized.

ryanberckmans commented Feb 15, 2018

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?

@Mushoz

This comment has been minimized.

Mushoz commented Feb 15, 2018

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.

@arsenicks

This comment has been minimized.

arsenicks commented Feb 15, 2018

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 ?

@jstoxrocky

This comment has been minimized.

jstoxrocky commented Feb 15, 2018

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.

@DanielRX

This comment has been minimized.

DanielRX commented Feb 15, 2018

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.

@shutfu

This comment has been minimized.

shutfu commented Feb 15, 2018

I am 100% against this as a long-time eth miner and supporter

@justbotrelatedthings

This comment has been minimized.

justbotrelatedthings commented Feb 15, 2018

This is nothing that should be on the Ethereum network.

@nootropicat

This comment has been minimized.

nootropicat commented Feb 15, 2018

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.

@Mushoz

This comment has been minimized.

Mushoz commented Feb 15, 2018

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.

@DanielRX

This comment has been minimized.

DanielRX commented Feb 15, 2018

@nootropicat @justbotrelatedthings

This is not a place for profanity. If you can't keep it civil, don't say it

@androolloyd

This comment has been minimized.

androolloyd commented Feb 15, 2018

100% opposed to this EIP it's very damaging to the future of Ethereum.

@brenthompson2

This comment has been minimized.

brenthompson2 commented Feb 15, 2018

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)

I am curious as to how having EIP Editors could effect the centralization of the platform. Can anyone direct me to this EIP-1?

@kamranrahman

This comment has been minimized.

kamranrahman commented Feb 15, 2018

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.

@mitucsaki

This comment has been minimized.

mitucsaki commented Feb 15, 2018

Do not support this

@julian-goldsmith

This comment has been minimized.

julian-goldsmith commented Feb 15, 2018

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

@ngerrity

This comment has been minimized.

ngerrity commented Feb 17, 2018

@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

@adamrabie

This comment has been minimized.

adamrabie commented Feb 17, 2018

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

@ngerrity

This comment has been minimized.

ngerrity commented Feb 17, 2018

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

@adamrabie

This comment has been minimized.

adamrabie commented Feb 17, 2018

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

@Cryptosophies

This comment has been minimized.

Cryptosophies commented Feb 17, 2018

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 ?

@realcodywburns

This comment has been minimized.

realcodywburns commented Feb 17, 2018

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

@adamrabie

This comment has been minimized.

adamrabie commented Feb 17, 2018

@realcodywburns <- most sensible, honest Ethereum defender here.

@Cryptosophies

This comment has been minimized.

Cryptosophies commented Feb 17, 2018

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.

@Lietmotiv

This comment has been minimized.

Lietmotiv commented Feb 17, 2018

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.

@IceAmaura

This comment has been minimized.

IceAmaura commented Feb 17, 2018

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

@Lietmotiv

This comment has been minimized.

Lietmotiv commented Feb 17, 2018

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

@Cryptosophies

This comment has been minimized.

Cryptosophies commented Feb 17, 2018

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

@rohanagarwal

This comment has been minimized.

rohanagarwal commented Feb 18, 2018

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

@cardassian-tailor

This comment has been minimized.

cardassian-tailor commented Feb 18, 2018

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:
it is intended to address cases where there is no disagreement about the right outcome between directly affected parties

First we are talking about instances of obvious error and no dispute.

Second, the ERP states:
This EIP does not advocate for or against the acceptance of any particular recovery proposals, nor would its acceptance alone result in any state changes to the blockchain.

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
No fund recovery options are available to be used because transactions are immutable.

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.

@MicahZoltu

This comment has been minimized.

Contributor

MicahZoltu commented Feb 18, 2018

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.

@kris-davison

This comment has been minimized.

kris-davison commented Feb 23, 2018

Strongly oppose this. I was not happy about the DAO decision please don't make that mistake again.

@whereskarlo

This comment has been minimized.

whereskarlo commented Feb 23, 2018

Completely opposed to this proposal. It makes ethereum fragile and pointless. It's either immutable or a waste of everyone's time. Choose one.

@taoteh1221

This comment has been minimized.

taoteh1221 commented Feb 24, 2018

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.

@intari

This comment has been minimized.

intari commented Feb 25, 2018

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?

@masterkrang

This comment has been minimized.

masterkrang commented Feb 25, 2018

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

@supRNurse

This comment has been minimized.

supRNurse commented Feb 25, 2018

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.

@necro-nemesis

This comment has been minimized.

necro-nemesis commented Feb 25, 2018

Comment moved to 867.

@muf18

This comment has been minimized.

muf18 commented Feb 25, 2018

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.
Just let them do it, nothing will stop them.

@adamrabie

This comment has been minimized.

adamrabie commented Feb 27, 2018

“Build unstoppable applications
Ethereum is a decentralized platform that runs smart contracts: applications that run exactly as programmed without any possibility of downtime, censorship, fraud or third-party interference.”

lol

@Cryptosophies

This comment has been minimized.

Cryptosophies commented Feb 28, 2018

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.

@giclo

This comment has been minimized.

giclo commented Apr 20, 2018

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.

@postables

This comment has been minimized.

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.

@postables

This comment has been minimized.

postables commented Apr 20, 2018

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

@Arachnid

This comment has been minimized.

Collaborator

Arachnid commented Apr 20, 2018

@ethereum ethereum locked as off topic and limited conversation to collaborators Apr 20, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.