The difficulty target moves every 2016 blocks, not continuously

Inherited archive entry · retained from the earlier edition. Its factual, legal and policy claims have not all been reverified for 19 September 2026. Research scope.

A recalculation on a fixed schedule

Bitcoin's proof-of-work does not stay a fixed difficulty. The developer guide's block chain chapter states that every 2,016 blocks, the network uses timestamps stored in each block header to work out how many seconds elapsed while those blocks were found. The ideal figure is 1,209,600 seconds, two weeks at a ten-minute average. If the interval ran short, the target tightens; if it ran long, the target loosens. The guide also flags a known quirk: an off-by-one error in Bitcoin Core's implementation means the recalculation actually uses timestamps from only 2,015 of those blocks, not 2,016. That detail matters for anyone reconstructing the exact arithmetic rather than the general idea.

Bounded moves, not free-floating ones

The adjustment is capped. Per the same reference, the target can loosen by as much as 300 per cent if blocks were found too quickly, or tighten by as much as 75 per cent if they were found too slowly. In practical terms, no single retarget can move the required work by more than a factor of four in either direction, however extreme the observed hashrate swing. The mining guide separately distinguishes this network difficulty from the easier share target a pool sets for its own accounting, set orders of magnitude lower purely to measure member contribution; conflating the two overstates or understates the real network figure.

A lagging indicator, not a live one

The original paper describes the goal plainly: difficulty is set by a moving average targeting an average number of blocks, and it increases if they are generated too fast. Because that average is only recomputed once every 2,016 blocks, a sudden change in hashrate is not reflected until the current period ends, up to roughly two weeks away. During that window, observed block times run measurably faster or slower than ten minutes, and a hashrate estimate backed out from the current difficulty describes the recent past, not the present. This is an editorial framework rather than a claim in the sources: treat any figure that infers a current network hashrate from difficulty alone as necessarily stale by up to one adjustment period.

Questions to carry forward

• Does a stated hashrate figure come from a direct measurement or is it backed out from the difficulty, and is that lag disclosed?
• Did the two-week window in question actually run close to 1,209,600 seconds, or is the claim describing a shorter, noisier sample?
• Is a mining-profitability claim assuming the current difficulty holds for a horizon longer than one retarget period?

The mechanism is a control loop with a fixed period and a bounded step, not a thermostat that reacts to the moment. That distinction is small in the specification and large in how confidently anyone should read a headline hashrate number.