Copy from Gitter:
Where does the number to delay the hard fork of 4,000,000 come from? My understanding of the reason for the bomb was to avoid a situation like in Bitcoin where ten people control when to fork. Here’s the scenario — all you’all decide (for whatever reason) that there should be no more changes forever. And whomever has the GitHub permissions to change the code are convinced as well. The rest of the community would then have no recourse. If you think this can’t happen–look at Bitcoin. Forcing ourselves to deliver a fork every so often, even if there are no substantive changes, forces the community to repeatedly come back into agreement…and it give whatever portion of the community that wants to a chance to fork off. A better way to remove the ‘pain’ of the ice age would be to better manage it and make sure it gets modeled better (so we know when it’s going to hit) and include it in forks as a regular course.
Correction: The 4,000,000 would be in addition to the 5,000,000 from previous forks (3,000,000 for Byzantium and an additional 2,000,000 for Constantinople). So the subtraction from the ‘real’ block number to the ‘fake’ block number would be 9,000,000. This will reset the fork ‘period’ to zero ((9069000 - 9000000 = 69000) % 100000) = 0
Another way to do this, which would be much more obvious would be to simply subtract the FORK_BLOCK_NUMBER from the ‘real’ block to arrive at ‘fake’ block number. This would reset the bomb to zero each time.
I think there’s a lot of confusion related to hash rate. The bomb, once it starts going off, totally dominates the difficulty calc.
The reason the bomb is going off earlier this time is because we only set it back to period 22 ((7280000 - 5000000) % 1000000) = 22, whereas in Byzantium we set it back to period 13 ((4370000 - 3000000) % 100000) = 13. Our goal should be to set the period back to 0.
The difficulty calc comes in two parts, A and B. A is designed to offset any change in hash rate by responding oppositely with higher or lower difficulty. Part A tends to hover at 14 seconds.
Part B (the bomb) grows exponentially based only on the period it’s in, and the period is dependent only on block number. The bomb totally dominates once it starts showing up. The non-bomb component (A – i.e. hash rate/difficulty) hovers.
A much more likely explanation for why the bomb is happening earlier than expected is because 2^22 is a lot larger than 2^13, and N months after the Byzantium fork we were in period 13 + X, whereas now we are in period 22 + X. (Where X is the number of periods the chain advances in N months.)
If we choose bomb_reset_subtraction = ISTANBUL_FORK_BLOCK we would make the period == 0 and fully diffuse the bomb.