Mining difficulty is calculated from the time difference between blocks. The exact formula will change in Homestead. The symbol // in the following denotes integer division.
block_diff = parent_diff + parent_diff // 2048 * (1 if block_timestamp - parent_timestamp < 13 else -1) + ...
If the timestamp difference (block_timestamp - parent_timestamp) is:
< 10 seconds, the difficulty is adjusted upwards by parent_diff // 2048 * 1
10 to 19 seconds, the difficulty is left unchanged
>= 20 seconds, the difficulty is adjust downwards proportional to the timestamp difference, from parent_diff // 2048 * -1 to a max downward adjustment ...
The difficulty bomb is a part of the consensus algorithm; its goal is to make the difficulty of mining a block arbitrarily hard at some point in the future. When active, it will get increasingly hard for miners to create new blocks and therefore will get block rewards less frequently; which means less revenues. Exponentially.
From the blog:
starting from ...
According to Vitalik Buterin on r/ethereum, the difficulty bomb was slowed down with homestead a bit.
As it turns out, with the change in the difficulty adjustment algorithm brought about in the last hardfork, the ice age will come very slowly indeed. Originally, the maximum amount by which the difficulty could adjust was 1/2048x, and so given a natural ...
The difficult bomb was actually added in a hard fork shortly after Ethereum's launch. It's not a necessary part of the protocol, and so if PoS isn't ready on time, it's most likely that another hard fork will delay or remove the bomb. In fact, if a portion of the Ethereum community desires to still use PoW, or does not agree with the final PoS protocol, ...
The changes to the code were made in August in this commit, with the meaty parts of the maths being found in core/chain_util.go.
The constant increase in difficulty is due to an additional exponentiation step in the algorithm.
A quick back-of-the-envelope calculation can be found here, and would suggest that after 22 months (from August 2015) the average ...
If all miners removed the difficulty bomb and basically reject the fork (or introduce a new one by removing it) then there would still just be one chain as there is nobody else creating any other chain. In this hypothetical scenario, if the miners were the only ones and all other node operators would still have the bomb in place, then these nodes would ...
Only a partial answer, and it might require someone who knows about Ethereum Classic (i.e. the ETC chain) to confirm...
This option was added during the addition of support for the Expanse network (EXP), under Parity issue #2369. However, I believe it's probably actually related to ECIP-1010, which is Ethereum Classic's (mainnet) delay of the Difficulty ...
That's the correct formula since the homestead development phase.
100000 is here a constant and according to How does the Ethereum Homestead difficulty adjustment algorithm work? :
+ int(2**((block.number // 100000) - 2))
The difficulty bomb part, which increases the difficulty exponentially every 100,000 blocks.
It seems this formula is ...
The Muir Glacier fork is a hard fork of the Ethereum network that delays the difficulty bomb. The fork is expected to happen on block 9,200,000 in January 2020 and will contain a single EIP, EIP 2387.
This fork delays the difficulty bomb 4 million blocks.
I believe we recently started a period where difficulty bombs in ETH
will have substantial effect, but it is surprisingly hard to find
throughout explanation about this online, hence the question.
Have a look at these previous threads:
When will the difficulty bomb make mining impossible?
What is the "difficulty bomb" and what is the goal of ...
Yes, you can defuse the bomb by adding the defuseBombTransition parameter to the ethash parameters in the chain spec json, like this:
The lower the value, the earlier the bomb is disabled. You can see this parameter in action for the expanse network.
Ethereum's algorithm would have been better if the max() had not been used. The parent_diff/2048*(1-t/10) could have been expanded to prevent the zero that results from integer division. This would have resulted in
diff = parent_diff + parent_diff/N - parent_diff*t/T/N
t = parent solvetime
T = target solvetime
N = extinction coefficient aka "mean ...
you might look at this post that explains how the difficulty is calculated
the script tries to predict diff from the 10th of may taking various params at that date into account
should you like to compare a prediction from block 200 000 to now with the reality you'd have to rewrite the script with a state prior to that block