Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Creates Remove Difficulty Bomb EIP #1240

Merged
merged 4 commits into from
Jul 21, 2018
Merged

Creates Remove Difficulty Bomb EIP #1240

merged 4 commits into from
Jul 21, 2018

Conversation

MicahZoltu
Copy link
Contributor

@MicahZoltu MicahZoltu commented Jul 21, 2018

The difficulty bomb operates under the assumption that miners decide what code economic participants are running, rather than economic participants deciding for themselves. In reality, miners will mine whatever chain is most profitable and the most profitable chain is the one that economic participants use. If 99% of miners mine a chain that no economic participants use then that chain will have no value and the miners will cease mining of it in favor of some other chain that does have economic participants. Another way to put this is that miners will follow economic participants, not the other way around.

With the difficulty bomb removed, when Casper is released it will be up to economic participants to decide whether they want the features that Casper enables or not. If they do not want Casper, they are free to continue running unpatched clients and participating in the Ethereum network as it exists today. This freedom of choice is the cornerstone of DLTs and making it hard for people to make that choice (by creating an artificial pressure) does not work towards that goal of freedom of choice. If the development team is not confident that economic participants will want Casper, then they should re-evaluate their priorities rather than trying to force Casper onto users.

Personal Note: I think we will see almost all economic participants in Ethereum switch to PoS/Sharding without any extra pressure beyond client defaults.

The difficulty bomb operates under the assumption that miners decide what code economic participants are running, rather than economic participants deciding for themselves. In reality, miners will mine whatever chain is most profitable and the most profitable chain is the one that economic participants use. If 99% of miners mine a chain that no economic participants use then that chain will have no value and the miners will cease mining of it in favor of some other chain that does have economic participants. Another way to put this is that miners will follow economic participants, not the other way around.

With the difficulty bomb removed, when Casper is released it will be up to economic participants to decide whether they want the features that Casper enables or not. If they do not want Casper, they are free to continue running unpatched clients and participating in the Ethereum network as it exists today. This freedom of choice is the cornerstone of DLTs and making it hard for people to make that choice (by creating an artificial pressure) does not work towards that goal of freedom of choice. If the development team is not confident that economic participants will want Casper, then they should re-evaluate their priorities rather than trying to force Casper onto users.

Personal Note: I think we will see almost all economic participants in Ethereum switch to PoS/Sharding without any extra pressure beyond client defaults.
MicahZoltu added a commit to MicahZoltu/yellowpaper that referenced this pull request Jul 21, 2018
EIP number TBD, will update once decided.
ethereum/EIPs#1240
@Arachnid Arachnid merged commit 3dae347 into ethereum:master Jul 21, 2018
@tjayrush
Copy link

This is exactly the type of EIP that exposes the shortcomings of the current process. The author should move this to Final Call with no further discussion. Conversation about this EIP will not be technical. They will be 100% philosophical.

Move it to Final Call. Watch as there are no real technical objections. Wait two weeks before it moves automatically to Final, and then let the Core Devs decide if they want to implement it. I, for one, hope they don't.

@MicahZoltu
Copy link
Contributor Author

Good point. @Arachnid, what is the process for moving to Last Call? Just update the status? I haven't received any technical feedback yet, and I suspect there won't be any.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants