How does the Bitcoin difficulty adjustment work?
Every 2,016 blocks, each node compares how long those blocks actually took with the two-week target (20,160 minutes) and scales mining difficulty by that ratio, limited to a factor of four either way. Faster blocks raise difficulty; slower blocks lower it.
The rule
Bitcoin aims for one block every ten minutes. Miners compete to find a block hash below a target; difficulty is a human-friendly way of expressing how small that target is. Because hashrate changes as machines are switched on and off, the protocol re-targets periodically:
- An epoch is 2,016 blocks. At ten minutes each that should take 20,160 minutes, or two weeks.
- At the end of the epoch, nodes compute: new target = old target × (actual time ÷ 20,160 minutes).
- The ratio is clamped to between ¼ and 4, so difficulty can change at most fourfold per adjustment.
Every node computes this independently from block timestamps; nobody votes on it.
A known quirk: Bitcoin Core measures the time across 2,015 block intervals rather than 2,016 (an off-by-one in the original code that is now part of consensus). The effect is tiny and does not change the explanation.
Reading the estimate in the log
Partway through an epoch, explorers estimate the coming change by assuming blocks keep arriving at the average pace so far. The daily log reports:
- Progress through the current 2,016-block epoch.
- Blocks remaining and the estimated date of the retarget.
- The estimated change in percent, and the previous change.
Example. If the average block so far has taken 9.38 minutes, the estimate is roughly 10 ÷ 9.38 − 1 ≈ +6.6%. If the average were 11 minutes, it would be about −9.1%. Our countdown page shows the current numbers.
Why block times drift
- Hashrate growth. New, more efficient machines come online faster than difficulty catches up, so blocks often run slightly faster than ten minutes in a rising market for mining hardware.
- Seasonal power. Some miners curtail in hot months or when electricity prices spike, slowing blocks.
- Randomness. Even with constant hashrate, block intervals are random. Over 2,016 blocks this averages out well, but over a few dozen blocks it does not.
Does difficulty matter for users?
Mostly indirectly:
- When blocks are running slow late in an epoch, fewer blocks arrive per hour, so the mempool clears more slowly and fee rates can stay higher.
- After a large downward adjustment, blocks speed back up and backlogs clear faster.
- Difficulty also shapes miner revenue, which matters more for long-term security than for any single payment.
Difficulty versus hashrate
Hashrate cannot be measured directly; it is inferred from how quickly blocks are found at a known difficulty. Short-window hashrate figures are therefore noisy. The log uses mempool.space’s three-day estimate and rounds it, because a figure like “1,033.87 EH/s” implies more precision than the method has.
Related countdown: the halving
The difficulty epoch (2,016 blocks) and the halving (210,000 blocks) are separate clocks. Neither depends on calendar time; both are counted in blocks, which is why their dates are always estimates.
Questions people also ask
- Does higher difficulty make transactions more expensive?
- Not directly. Difficulty sets how hard it is to find a block, not how much space a block has. It affects fees only indirectly, through block timing during an epoch.
- How accurate is the estimated difficulty change?
- It extrapolates the average block time so far in the epoch. Early in an epoch the estimate swings widely; in the last few hundred blocks it becomes much more reliable.
Sources
- Bitcoin developer guide: Block chain and proof of work
- Bitcoin Core source: pow.cpp (CalculateNextWorkRequired)
- mempool.space REST API: difficulty adjustment
Prepared by Daily Crypto News from the sources above. Published 2026-10-15; last reviewed 2026-10-15. See our editorial standards. Not financial, tax or legal advice.