Skip to content
This repository has been archived by the owner on Oct 4, 2019. It is now read-only.

Defusing the difficulty "bomb" #11

Closed
rawodb opened this issue Aug 1, 2016 · 21 comments
Closed

Defusing the difficulty "bomb" #11

rawodb opened this issue Aug 1, 2016 · 21 comments

Comments

@rawodb
Copy link

rawodb commented Aug 1, 2016

I propose we defuse the difficulty "bomb" in the next updates.

Code: https://github.com/ethereumproject/go-ethereum/blob/master/core/block_validator.go#L303

Remove lines 305-309 and it should be alright.

Toughts?

@whatisgravity
Copy link

whatisgravity commented Aug 1, 2016

Thank you for opening the topic on this subject.

In my opinion, I think we should try to use this opportunity to update anything we need updated in the protocol. To begin we would need a base patch that can be tested. If the base patch proves itself, then people can begin submitting proposals built on top of the base patch to defuse the bomb.

I need more time to review the code to determine if this is the change needed but I encourage others to begin reviewing this proposed fix and if it is not adequate make counter proposals. Once we can agree on a base patch we can move forward from there.

@rawodb
Copy link
Author

rawodb commented Aug 1, 2016

edit I don't understand why I have the ability to edit this comment. I apologize for accidentally overwriting your message.

@redsn0w0
Copy link

redsn0w0 commented Aug 1, 2016

Thanks @rawodb , I agree with @whatisgravity.
It will be the right opportunity to change few things about ETC.

@whatisgravity
Copy link

@rawodb If you have no already, consider volunteering with the community development initiative. https://github.com/ethereumproject/Volunteer

@jwg4
Copy link

jwg4 commented Aug 3, 2016

I think that we shouldn't rush to make changes like this. Lots of people might be switching between the two chains, including miners, payment processors. Any change which requires all full nodes to update should be delayed until the dust has settled. Anything else will encourage FUD about incompatibility and lack of direction.

@whatisgravity
Copy link

No one is rushing to make changes, we are preparing patches early so we have time to test and peer review proposed solutions.

There is no reason currently to implement the defusal until we need to, but we should have something ready when that moment arrives.

@whatisgravity
Copy link

So far we have one proposal:
#12

@whatisgravity
Copy link

whatisgravity commented Aug 3, 2016

@rawodb I accidentally edited your comment, I'm not sure why I have that ability.

The change will not fork the 'blockchain'.

A very quick skim indicated to me that you may be correct, I will have to look further into the topic but it appears from skimming what you linked we may be able solve the defusal with a soft fork, which in my opinion should shift the priority, we may wish to resolve this sooner if this is possible.

To confirm this we need to look wherever incoming blocks are being validated.

@arvicco
Copy link

arvicco commented Aug 3, 2016

If our chain is not able to attract majority of hash power, we will feel the effect of diff bomb much sooner than the dominant chain. Even though there is no rush right now, my understanding is that things become difficult for us by the end of this year. So disarming diff bomb should not be delayed too much. Please keep in mind that we cannot expect EF devs helping us with this change, and the change needs to be synchronous across a range of supported clients.

@whatisgravity
Copy link

whatisgravity commented Aug 3, 2016

@arvicco I'm confident we will have a solution coded and tested before it affects miners, I encourage everyone to familiarize themselves with the situation so we can increase the number of people looking at this problem.

After it is ready, we will need to coordinate the best way to deploy it. I can say more once I have more information after I investigate it enough to put together a proposal myself.

@julian1
Copy link

julian1 commented Aug 3, 2016

I've not looked closely at this, but it's another project's defusing.

etheregen/go-ethereum@e001174

Definitely needs testing in a simulator type environment.

@bragcustom
Copy link

If Ethereum Classic wont go to POS then miners can mine at higher difficulty(eg with exp bomb) so users(non-mining nodes) will have time to switch to version without the bomb. Otherwise it will lead to chain-fork which is undesirable

@jwg4
Copy link

jwg4 commented Aug 4, 2016

Technically this is a hard fork. Miners which adopt the change will sooner or later create a block which will be considered invalid by miners who have not updated (because its difficulty will be considered too low). Someone who does not update will not by default adopt this blockchain (the definition of a successful soft fork).

@bart-w0
Copy link
Member

bart-w0 commented Aug 4, 2016

I agree with @jwg4 and his explanation.
This is a protocol change that should be implemented across all clients in the same way (I am EthereumJ dev). I understand that this might be simple "remove-diff-bomb-code" change, but we need to plan it in a generic way at the protocol-level. I think it is too early for submitting code proposals. However, it's good to know how big the change will be, while planning.

@jwg4
Copy link

jwg4 commented Aug 5, 2016

In my opinion the right way to do this is with some form of 'voting' among miners for support for the switch. Not because it is controversial, but because the risk of breaking compatibility is too serious.

@yolandaruiz
Copy link

We should also consider the ramifications of a scenario where a non-negligible portion of miners and clients do not update to this change, and list all the issues that could arise, and have contingency plans.

@ocminer
Copy link

ocminer commented Aug 7, 2016

If you guys are interested I can set up a voting poll on my pool https://etc.suprnova.cc so that miners can actually vote about the removal of the bomb. I for myself am high encouraging the removal.

@whatisgravity
Copy link

If I understand, some people are proposing putting a new "difficulty bomb". I recommend we simply just remove this, imposing arbitrary deadlines does not have any obvious advantages from my perspective.

@realcodywburns
Copy link
Contributor

I created a repo for investigating and testing bomb strategies. The main argument for keeping the exponential diff adjustment is that we are forced to have a discussion with the miners on the topic of PoW vs some other system. If the threat of mutually destruction is removed, there is no incentive for miners to ever move to a system with less payout than PoW gives them.

@whatisgravity
Copy link

whatisgravity commented Aug 23, 2016

@realcodywburns: Good points, there are positives and negatives to each action. We should carefully consider them.

Are you familiar with writing tests? Writing a tests for this problem would be incredibly helpful first step.

Once I finish the second release of go-ethereum and finish a first official release of Mist I will jump onto the difficulty bomb situation.

Thanks for taking the initiative on this. Do you think we should just adopt the rearming strategy? How long do you think we should put it off?

@arvicco
Copy link

arvicco commented Sep 19, 2016

ethereumproject/ECIPs#4

@elaineo elaineo closed this as completed Sep 29, 2016
sorpaas pushed a commit that referenced this issue Nov 21, 2017
fixed vm.Log[s] to state.Log[s]
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests