@dpyro Everything you have said outlines exactly enough reason to discontinue this EIP.
Frankly, I am disgusted that this discussion has been moved away from the perfectly functional and familiar GitHub to this other forum (which needlessly makes the newest posts very inaccessible).
Fortunately I highly doubt this EIP will get any further.
(edited for clarity)
@bwheeler96, can you elaborate on why this has disgusted you?
I am also confused about how an objection to where we are discussing EIPs relates to why one would support or reject a proposal.
For more background on why FEM set up this discussion forum: we are attempting to improve on the evaluation of proposals with categories, topics, and the ability to reply to a specific post. This approach to discussing complex issues is something that Ethereum Research has used effectively at https://ethresear.ch.
@jpitts for one, this site does not work very well. Also I don’t see a lot of other EIPs here, except 867 which is basically the same EIP in different wording. Secondly, this site doesn’t work very well if we’re being honest.
It very much feels like an attempt by the people that are heavily involved with this EIP to stifle discussion by people that don’t agree.
The site works great for me, what problems have you run into with it?
This site is fairly new, and the concept of having EIP discussions here is even newer which is why you will only find a couple discussions here.
I’m sorry that the site doesn’t work well for you and feels like a way to stifle discussion about a specific EIP, @bwheeler96.
The origins of this website are in the ethereum/governance gitter channel. While ether recovery is a topic that is widely discussed in the community, it was not very strongly in our mind when @gregc and I began work on the Fellowship. The goals are more general for this group and this website.
We are using Discourse software here and learning about how it works. Let’s open a new thread on site feedback if you want to discuss how the site doesn’t work well.
It would be good if the ordering of posts was more chronological. Putting oldest posts first does not feel very effective, and on top of that I have to scroll a lot (with stops for lazy-loading) just to get to the bottom. Other than that the site is very nice.
What I particularly don’t like is that ethereum-magicians is a new site that developers have to sign up for, making it a few extra steps of difficulty for people to have this discussion. It seems like a conversation that was well in the public eye (Github) has been moved to this other site that essentially does the same thing but is less accessible to the general public (of developers).
Lets keep conversations out in the open.
Added.
(20 characters)
I am not sure how such a decision should be made. Is it going to be counting hands? If so I would like to add my hand in the “Rejection of this proposal” camp.
The points made by fellow posters already (@alexvandesande especially) are the reason why I am opposing this. This would definitely cause another chain split and I just don’t want to impose this to the Ethereum community.
I am strongly against this proposal since it doesn’t directly improve Ethereum, I rather have Parity have another ICO/donation address to get some of the funds back.
Also , please watch this … don’t make it happen please.
Immutability is the difference between a decentralized platform and an inefficient hosting service. There’s no point for ethereum to exist if it’s mutable.
Put another way, ethereum with bailouts is a poorly scalable and inefficient version of EOS, which is a poorly scalable and inefficient version of AWS Lambda.
Events in the past (the dao fork) don’t matter by itself, because well, they already happened, whether it was a mistake or not. What matters is the future: was that change a one-off, or the start of a pattern.
To add to your points Alex, I would like to put emphasis on tokenized physical assets. Tokenized plane tickets, house ownership and similar tokenized real life assets will all need to choose a single chain to support. You can’t fit more people in a plane than there are seats, just like someone can’t own “two” houses.
These applications can only support a single ledger and a contentious fork without a proper governance scheme could seriously damage their platform. We could end up having apps that definitively choose different chains and end up being somewhat permanently separated from each others (until chain inter-operability, but that’s still quite a burden).
There could be “chain” migration methods implemented in their contracts, but I doubt most applications currently implemented this.
Playing devil’s advocate here and please feel free to tear this apart, especially incorrect assumptions:
Is this considered an “improvement” to the protocol as identified in the definiton of Standard Track / Core proposals? If it is should “improvement” be further clarified in EIP-1 or removed and replaced with “change” or something with a little bit more flexible a definition. If it isn’t an “improvement” under the conventional definition of the term, or as intended in EIP-1, should EIP-999 remain open/be merged or closed/withdrawn?
Based on 1, should EIPs be requested to demonstrate their benefit to the Ethereum ecosystem/protocol (as it stands now the benefit for EIP-999 seems to begin and end at a small interest group versus all users/participants).
If the EIP isn’t concerned with any protocol level improvements or protocol level remediation efforts, is this a topic the Core Devs should be spending much time on? If one of the beneficiaries of the EIP weren’t a highly influential client development team, would the matter be something the Core Devs would spend significant time discussing, except maybe for technical viability once community consensus is gauged? If clear consensus is never reached (as it appears with this), should the Core Devs devote time to discussion at all.
The problem I see here is there is a lot of attention being paid to this because Parity is a major and highly valued member of the community. If we remove Parity from the equation, I think generally the sentiment would be “you’re free to explore other recovery options, or attempt your own fork.” Because this is a valued team, we don’t want it to come to that, so certain accommodations have been made, which is understandable, and I’m not sure how to resolve this in a way that is beneficial to Ethereum and Parity / The Other Affected Parties.
I want everyone to get their ETH back, but I don’t know if a contentious fork is the way to do it. Nor if it’s something the Core Devs or EIP process are designed to facilitate, being extraprotocol and all.
This is the most eloquently put advocation of immutability I have ever seen. If we fail to be immutable, we fail.
I’m not sure I agree. Immutability is a goal, but it isn’t a promise, not even with blockchains. I’d argue true immutability doesn’t exist, since agreed upon changes can be made as part of the on-chain governance process.
Immutability tends to result from bad governance processes incapable of, or unwilling to, handle classes of changes. The decision not to address classes of changes is also a decision, and should be made only with input from all, and revisited as a network matures / grows. I argue Bitcoin’s claim to immutability is actually a function of a centralized decision to not deal with classes of changes that their governance process is ill equipped to handle, or they simply refuse to out of some dogmatic belief. They’ve also not had to deal with a test of that conviction, except for early on when previously valid transactions creating 184bn Bitcoin were invalidated through human intervention.
Off-chain governance aside, the blockchain is capable of deciding these things and is the natural venue for such hard decisions. Off-chain governance just seeks to gauge sentiment and whether putting it to the blockchain even makes sense.
Aside: How do I quote on mobile lol?
On a top level, I support a process that enables clear-cut recoveries when possible. I believe that in the long run Ethereum needs such a mechanism to keep growing and compete in this space. If the risks are too high and there are other chains that enable such recoveries, I think the bigger players will just move to other chains.
The whole ERP process while it sounds good, I do not support it yet. I think it’s too soon and before it is accepted alternatives need to be thought out. If it turns out to be the best way - that is fine, but a clear group / process with responsibilities must be thought out before. We really should not put it all on developers to decide.
As for this EIP - I support EIP999 because it’s a clear cut thing that’s quite easy to implement and when included in another hard-fork really isn’t a big risk of splitting the chain.
Regarding EIP-999 discussion on the 4/20 core dev call:
A: Me:
Yes. Contentious EIPs/initiatives are given due discussion time but there is a certain level of contention at which they aren’t deserving of the implicit coordination and development work of all core developers to build out the contentious solution and time a fork.
That work can be left to the forker.
Initiatives that have consensus get core dev coordination, initiatives that don’t, get tabled indefinitely within the core dev forum.
I believe ethereum core development, as an organization, should strive to focus on highly agreed-upon initiatives and initiatives that improve the protocol as a whole. Individuals and other groups are always able to coordinate under a different community brand.
The core developer organization should not be required to divide itself at the behest of interested parties without very good reason (reasons that garner the consensus of the core dev organization).
At DevCon2, Piper Merriam was issuing the DevCon2 token. There were 231 coins issued.
At the time, there was some discussion that these tokens might be used for voting. How difficult would it be to set up a voting dapp for holders of DevCon2 tokens?
Might that be a way to get a sense of the feelings on this issue from “relatively” early adopters who we are certain are ( a ) not sybils, ( b ) not weighted by ether holdings, and ( c ) known to have been at DevCon2.
Here’s some information on those tokens: https://github.com/pipermerriam/devcon2-token, https://medium.com/@pipermerriam/devcon2-token-upgrade-fa9fa4af59b5, and https://etherscan.io/token/devcon2.
Just to add to other options for types of votes. I have a database of usernames, date of first post, and karma from the top 4 ethereum subs. I’ve made the tool I used to scrape this available so the results can be checked. People register this data on-chain when they register to map an ethereum address to their username via the r/recdao project. Currently 700 people have pre-registered an address. Possibly this data could be used to formulate some threshold criteria for different kinds of votes.
Whether or not we fail is dependent on what our objectives are.
We are free to define our own objectives but meeting those objectives does not imply that we have provided any real value; I can build a trivial system that is immutable, decentralized, and absolutely useless. If my objectives are immutability and decentralization, I can declare success (imagine a big “Mission Accomplished” sign flapping in the wind behind me). However, I don’t think that’s why we’re all here.
Re: EIP999 Hardfork proposal.
If it ain’t broke, don’t ‘fix’ it
Ethereum is working just fine as intended. Learn from it, write better code. Parity messed up even AFTER the first multisig exploit. Now they are learning the lessons as they go along, just like EVERYONE else.
Are we going to ‘fix’ that one as well? I don’t see any discussion on that. Why? Because they didn’t lose THEIR funds in that failure it seems. This failure was caused by PARITY, not ETHEREUM.
If it was caused by the PROTOCOL, sure fix it and return the funds. But it was not.
They only have themselves to blame, unfortunate for them.
I will not support bailouts for Parity when there are thousands of people who are NOT going to be bailed out in a similar respect.
Supporting EIP999 is goes against the very nature of non-censorship.