ECIP-?: Extension of ecip 1010 timeline

[realcodywburns]

Abstract

The original ECIP 1010 ( #4 ) describes the details of delaying Difficulty Bomb growth for one year. It was suggested to change Difficulty Bomb formula to stop growing for period of time from January 2017 to December 2017, which is around blocks 3,000,000 and 5,000,000 accordingly. This would correspond with the end of era 1 per ECIP 1017 ( #15 ) and implementation of the new monetary policy.

History

The bomb was originally delayed to review:

• Monetary Policy
• PoW/PoS or Hybrid
• Replay Attack
• DAG growth
• Difficulty Bomb

Several of these items have been addressed, several more have been added in the past year including evm evaluation, file storage, and sharding.

ECIP

I propose remaining at the current difficulty, extra difficulty 2**28, until block 9,000,000 or render safe forever (setting the default unfreeze block to 0x7fffffffffffffff) as part of the activation of ECIP 1017.

Activation

This ECIP should be activated with an 'opt-out' flag. User wishing to keep the current ecip-1010 deadline should be allowed the option to use a --diehard flag which will keep the bomb reactivation at block 5m. the default action (no flag) will be to move the bomb block to 9m

[sorpaas]

I agree. Right now the protocol works well for us. Setting it to 0x7fffffffffffffff would allow us to completely eliminate the difficulty bomb problem as we're staying PoW, and so we can focus on other much more important work.

[sorpaas]

@realcodywburns Probably you meant that this should be as part of the activation of ECIP-1017 (monetary policy) as ECIP-1015 (the one about long-term gas cost changes) has already been activated?

[realcodywburns]

correct 1017- monetary policy - edited to correct

[elaineo]

I'm in favor of removing the bomb forever.

[splix]

I'm in favor of removing it too.

We may want to make another protocol upgrade after block 5M. That bomb will motivate to do it, say at block 6M. At this block we can do upgrades and remove bomb finally.

[drd34d]

I'm in favor of removing the diff bomb too.

[OmniEdge]

I am in favour to remove the bomb forever too.

[dollebrekel]

I am in favor of removing the bomb.

[carlox757]

I am in favor of removing the bomb.

[TheCrowbill]

I support complete removal of the difficulty bomb.

[Dexaran]

I'm not in favor of removing the bomb.
Rationale:
Bomb is the mechanism for controlling miners.
Ethereum is facing problems with miners right now. Miners are passive and they are not interested in chain progress. They are mining money, not ETC. They don't care about ETC at all.

If miners would have a choice:

1. Do nothing
2. Update the node to perform a hardfork that will introduce a lot of useful updates

then they will chose point 1 just because its easier for them and they don't need to do something.

If we remove the difficulty bomb, then in any disputable situation, when the miners would be interested in not accepting a fork, we will not be able to do anything with them. They will stay in the previous version of the chain forever and continue to mine blocking any development without any problems.

I suggest keeping the bomb and delaying it with regular forks.

[drd34d]

Mind me saying but your logic makes no sense to me.

If it's useful updates, then the miners best interest is to update the nodes.

Useful updates create a better valuation of the coin, thus more profit for miners.

You say miners don't care about ETC, they care about money.

With the bomb being kept, ETC shows that it doesn't care about the miners if it can find another way to secure to chain.

[drd34d]

taking your words and applying it reversed would be a valid point too:

If we don't remove the difficulty bomb, then in any disputable situation, when the developers would be interested in forcing a political fork, we will not be able to do anything with them.

[elaineo]

@Dexaran we have had HFs before, for updates (EIP-160, 155, ECIP-1010). Minor updates that are good for entire ecosystem are well-received.

The purpose of the bomb is to force a contentious HF. Ethereum-F put it in for PoS because that is obviously contentious for miners.
We took advantage of it for monetary policy: With the Monetary Policy, it took 8 months of discussion and coordination to get all the big mining pools to commit to adoption. Even now, not everyone is happy about the MP. I don't think ETC should have any more contentious HFs in the future.

[sorpaas]

I think we have mostly reached the agreement that the bomb should be removed. Thus it's time to discuss the fork block number.

I would be in favor of setting the fork block number at 5M because:

1. We haven't yet received objections to diffusing the bomb from miners or companies working in Ethereum Classic. It is unlikely that this diffusion would cause any political community split even it accidentally has the same fork block number as ECIP-1017.
2. This is a technically simple hard fork (one or two line changes in all current existing clients), and is extremely unlikely to introduce any new bugs. If we do this in a later block number, however, at least for some clients it would introduce a considerable number of new codes, and introduce the risk of new bugs.
3. The current difficulty level has been tested since block 3M without any problem. Forking at 5M allows to maintain this. We don't yet know that if we let the bomb ticking for a little bit more would cause any trouble.

[sorpaas]

From the discussion in this issue, it seems that a) most people agree to diffuse the difficulty bomb forever, and b) fork block number is not something under debate. So I think probably we can move on and accept this ECIP using the originally proposed fork number (5M) if there's no objections?

@realcodywburns, maybe you can create a new PR of this ECIP1010 extension and assign it an ECIP number?

Long live Ethereum Classic and may the bomb never bothers us again. 😃

[splix]

My objection against block 5M was that it looks like we're using bomb to enable new monetary policy

[realcodywburns]

From a UX perspective, it can be shifted to 0xfff..... and no clients will miss a beat as long as it is done before block 5m. I would like to hear some kind of input from IOHK's @mcsherrylabs or @CharlesHoskinson

[sorpaas]

Yes, we can announce that the fork block number is 4900000 or something like that. This is equivalent as forking at 5M. In this way, it avoids any association with the monetary policy hard fork.

My main objection against a later fork number, still, as stated earlier, is the unnecessary increase in code complexity and non-clear benefits in the political side, as diffusion of difficulty bomb seems to be something that most people agree.

Anyway, no matter what fork block number we decide to use, 5M or 6M or later, I highly suggest to reach a decision soon. If we let this pass November without a decision, there's a higher risk for a community split.

[sorpaas]

Another problem to fork at a later block than 5M is that the bomb raises the difficulty in plain number regardless of the current hash power. We have less than 1/10 of the hash power compared with Ethereum. So although Ethereum made it to September 2017, we may not make it to September 2018. And it is really difficult to anticipate whether there's any catastrophe associated with a steeper increase in difficulty. If we made this difficulty bomb diffusion into an emergency hard fork, that would be a little bit embarrassing.

Edit: I might be wrong about the above part. Please see ECIP-1010 for a complete analysis of the growth in block time (with the assumption that network hash rate stays constant).

@splix Are you okay with hard forking at block number 4900000? Or you can propose another hard fork number. If we can agree on that, it would also work. I'm just a little bit worried that, if we failed to move forward an ECIP like this, which as far as I know, has majority of agreement, it may cause people to lose trust in the ECIP process and might potentially split the community.

[OmniEdge]

"The bomb was originally delayed to review: Monetary Policy, PoW/PoS or Hybrid, Replay Attack, DAG growth and Difficulty Bomb."

Should we wait to diffuse the bomb forever to have leverage in case of a hybrid switch? For a softfork a majority of mining power is required.

[mcsherrylabs]

(@realcodywburns no objections to disabling the bomb permanently .... )

[RorschachRev]

I'm afraid the DAG problem never got addressed. The current dag is from 1.8 mil blocks and the next era at 5 mil with GOTHAM will trigger a new DAG if I understand correctly. From that point on, each era is 5 mil blocks. ETH solves the DAG growth with an era every 30k blocks. What is the projected block growth at block 9.9/10 mil? As the hash rate increases, this DAG growth will speed up.

[elaineo]

@RorschachRev see this issue: #6

[whilei]

I suggest to close this PR and use ECIP-1036: Fallback Complete Difficulty Bomb Diffusion to extend the spirit of this PR along with specific and attainable values (eg. block 5452163, 5123456).

[realcodywburns]

Closing, this repo is depreciated . To be reopened on http://github.com/ethereumclassic/ECIPs