The Difficulty Retargeting Algorithm

The target sets how hard each block is to mine. But hashrate is not constant — it has grown by many orders of magnitude over Bitcoin’s life and dips whenever miners power down. If the target were fixed, blocks would have arrived seconds apart by now. So Bitcoin does something quietly remarkable: it measures its own speed and retunes the difficulty to compensate, with no committee, no oracle, and no human in the loop. This page is that feedback loop.

Why a stable block time matters at all

The ~10-minute target interval isn’t sacred for its own sake — it’s a balance. It must be long enough that a freshly mined block can propagate to most of the network before the next one is found (otherwise honest miners constantly waste work on competing blocks, raising the orphan rate and weakening security), yet short enough that users get confirmations in a tolerable time.

A stable interval also matters for everything built on top: the halving schedule is denominated in blocks, so a steady block time keeps the issuance schedule roughly on its ~4-year calendar; timelocks measured in blocks behave predictably; and the most-work chain rule relies on attackers not being able to cheaply manufacture work. Difficulty adjustment is what keeps all of that anchored as the world’s hashrate swings.

The algorithm: every 2016 blocks

The rule is mechanical and the same for every node:

Every 2016 blocks (about two weeks at 10 minutes each), look at how long those 2016 blocks actually took, and scale the target so that — had this difficulty been in force — they’d have taken the intended time.

   intended_time = 2016 blocks × 10 minutes = 20,160 minutes = 14 days

   new_target = old_target × ( actual_time_of_last_2016_blocks / 20,160 minutes )

Read the ratio carefully:

• If the last 2016 blocks came too fast (actual < 14 days), the ratio is < 1, so the target goes down → mining gets harder → blocks slow back toward 10 minutes.
• If they came too slow (actual > 14 days), the ratio is > 1, so the target goes up → mining gets easier → blocks speed back up.

It’s a negative-feedback governor. Faster than 10 minutes? Tighten. Slower? Loosen. The “speed” being measured is just the timestamps in the block headers.

Two worked examples

The network sped up. Suppose a wave of new ASICs came online and the last 2016 blocks took only 7 days instead of 14:

   ratio = 7 days / 14 days = 0.5
   new_target = old_target × 0.5      (target halves → difficulty doubles)
   → blocks were arriving ~every 5 min; now the puzzle is 2× harder → back to ~10 min

The network slowed down. Suppose a large region of miners went offline and the last 2016 blocks dragged out to 28 days:

   ratio = 28 days / 14 days = 2.0
   new_target = old_target × 2.0      (target doubles → difficulty halves)
   → blocks were arriving ~every 20 min; now the puzzle is 2× easier → back to ~10 min

The system always pulls back toward the ~10-minute average, and it does so the same way on every node, so everyone computes the identical new target — no agreement needed beyond running the same code.

The ±4× clamp

The adjustment is capped: a single retarget can change the target by at most a factor of 4× in either direction. If the measured ratio is below 1/4 it’s treated as 1/4; if above 4 it’s treated as 4.

   allowed range of new_target = [ old_target / 4 ,  old_target × 4 ]

Why clamp it? To limit the blast radius of a sudden, huge hashrate shock or a manipulated set of timestamps. Even a wild swing can only move difficulty fourfold per period; anything larger is absorbed across multiple subsequent retargets. It’s a safety rail on the feedback loop.

The off-by-one “timewarp” bug — handle with care

The original code contains a subtle off-by-one error. To measure how long 2016 blocks took, you’d expect to compare the timestamps of the first and last block of the window — 2015 intervals. But the implementation actually spans only 2015 blocks’ worth of timestamps while issuing 2016 blocks, and it uses the previous window’s last block as a boundary in a way that doesn’t quite line up. In normal operation this is a harmless rounding quirk. The danger is the timewarp attack: if a majority of miners colluded to set deliberately false timestamps near retarget boundaries, they could trick the algorithm into lowering difficulty far below what real elapsed time warrants — minting blocks (and subsidy) faster than intended. It has never been exploited on Bitcoin’s main chain, and fixing it cleanly requires a soft fork because the buggy arithmetic is itself part of consensus.

Timestamps aren’t fully trusted

Block timestamps are loosely policed, not exact. A block’s time must be greater than the median of the previous 11 blocks and no more than ~2 hours ahead of network-adjusted time. Those bounds keep an individual miner from lying egregiously about when a block was made — which is exactly the input the retarget formula depends on.

The thread

How does this help untrusting strangers agree on one ledger? Difficulty adjustment makes the cost of producing a block predictable and self-correcting without anyone in charge. No matter how much hashrate joins or leaves, the network re-prices the puzzle so that history keeps accumulating at a steady, known rate. That steadiness is what lets strangers reason about finality: “six blocks” is a meaningful amount of work because each block represents a roughly constant, market-set quantity of energy — held there by this loop.

Check your understanding

1. State the retargeting rule in one sentence, including the period and the intended time.
2. The last 2016 blocks took 21 days. Which way does the target move, by what ratio, and what happens to difficulty?
3. Why does the protocol clamp adjustments to ±4× per period?
4. In plain terms, what is the timewarp bug, and why does it require a soft fork to fix rather than a quick patch?
5. Why does a stable block time matter for orphan rates and for the halving schedule?