Defusing the difficulty "bomb"
rawodb opened this issue · comments
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?
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.
edit I don't understand why I have the ability to edit this comment. I apologize for accidentally overwriting your message.
Thanks @rawodb , I agree with @whatisgravity.
It will be the right opportunity to change few things about ETC.
@rawodb If you have no already, consider volunteering with the community development initiative. https://github.com/ethereumproject/Volunteer
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.
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.
So far we have one proposal:
#12
@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.
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.
@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.
I've not looked closely at this, but it's another project's defusing.
Definitely needs testing in a simulator type environment.
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
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).
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.
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.
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.
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.
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.
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.
@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?