Every node recalculates the target every 2016 blocks (roughly two weeks, since 2016 × 10 minutes ≈ 20,160 minutes) by comparing the actual time taken to produce those 2016 blocks against the expected 20,160 minutes. If blocks came faster than expected, the target decreases (difficulty rises); if slower, the target increases (difficulty falls).
The new target is the old target multiplied by (actual time elapsed ÷ expected time), which is then clamped: no single adjustment can change difficulty by more than a factor of 4 in either direction, even if hash rate swung more dramatically than that within the period. This bounds how fast the network can react and prevents a single anomalous reading from causing extreme swings.
This mechanism is what makes Bitcoin's ~10-minute block time and therefore its predictable issuance schedule hold regardless of how much total computing power ever joins or leaves the network, whether that is a handful of hobbyist machines in 2009 or the industrial-scale mining of today.
Explain more simply
Bitcoin aims for one new block roughly every 10 minutes. If more miners join and blocks start coming faster, the puzzle needs to get harder to slow things back down.
Every 2016 blocks, about two weeks, the network looks at how long that batch actually took and adjusts the difficulty up or down to aim for ten minutes again.
Real-world analogy
It is like a treadmill that checks your average speed every two weeks and adjusts its incline so you keep taking about the same time per mile, whether you are jogging alone or a crowd of new runners just joined.
Key facts
- Difficulty is recalculated every 2016 blocks, roughly every two weeks.
- The target is scaled by (actual time ÷ expected 20,160 minutes), clamped to a maximum 4x change.
- This mechanism keeps the average block time near 10 minutes regardless of network hash rate changes.
Common misconception
“Difficulty adjusts continuously, block by block, to keep timing perfectly exact.”
Difficulty only changes at fixed intervals of 2016 blocks. Between adjustments, block times can vary quite a lot around the 10-minute average due to the randomness of proof of work.[2]
Go deeper
The calculation uses timestamps from block headers, which miners have some limited latitude to set (subject to a median-time-past rule and a maximum future-drift check), so the adjustment is an approximation rather than a perfectly precise measurement, though in practice it tracks real elapsed time closely over a 2016-block window.
A sudden, large drop in hash rate, for example a regional mining ban, can cause a temporary stretch of slower blocks until the next retarget, because the previous difficulty was calibrated for hash rate that no longer exists; the ±4x clamp bounds how quickly the network recovers from such a shock.
Quick check
Answer every question correctly (100%) to complete this lesson.
1.How often does Bitcoin's difficulty adjust?
2.What limits how much difficulty can change in a single adjustment?
Counts towards your streak in this browser.
Extra exam questions
Every question here counts towards your accuracy, XP and rank. No guessing: every answer is explained.
Quick check
Answer every question correctly (100%) to complete this lesson.
1.How often does Bitcoin's mining difficulty adjust?
2.What is the target average time between blocks that difficulty adjustment aims to maintain?
3.If the previous 2016 blocks were found faster than expected, what does the difficulty adjustment do?
4.What is the maximum adjustment factor difficulty can change by in a single retarget under the original consensus rules?
5.What data does the difficulty adjustment algorithm use as its main input?
6.If a large amount of hash power suddenly leaves the network, what temporarily happens to block times before the next retarget?
7.Does difficulty adjustment change the total 21 million bitcoin supply cap?
8.Why is difficulty adjustment important for Bitcoin's stability as mining hardware improves over time?
Counts towards your streak in this browser.
Sources
- Bitcoin Core documentation, Bitcoin Core project
Reference implementation documentation, including validation and release notes.
- Bitcoin: A Peer-to-Peer Electronic Cash System (2008), Satoshi Nakamoto
The original nine-page proposal. Describes proof of work, timestamping and the incentive model.