Protocol & Mining
The difficulty adjustment, and the ten-minute target
Bitcoin Core 28.x consensus rulesSource: Bitcoin Core consensus documentation; Bitcoin Optech difficulty topic indexThe retarget interval and the adjustment caps are consensus constants and carry no data vintage.
The rule, stated plainly
The protocol divides the chain into retarget periods of 2,016 blocks. At the last block of each period, every node independently computes the time that elapsed across the interval — from the timestamp of the first block in the period to the timestamp of the last — and compares it with the 20,160 minutes that 2,016 ten-minute blocks would take. The ratio of actual time to expected time becomes the adjustment factor applied to the difficulty.
If the interval took less than two weeks, blocks are arriving too fast, so difficulty rises. If it took longer, difficulty falls. The new target is the old target multiplied by the ratio of actual to expected time, and the new difficulty is its reciprocal. Because every node performs the same arithmetic on the same headers, the result is deterministic: there is no vote and no discretion, and a node that computed a different difficulty would reject the block that used it.
The choice of 2,016 blocks is a compromise between responsiveness and stability. A shorter interval would track hash-rate changes more closely but would also let a single lucky or unlucky stretch of blocks move difficulty sharply. Two weeks is long enough that the sample averages out most of the variance in block discovery, and short enough that a sustained change in mining capacity is corrected within a fortnight rather than a season.
The four-times and one-quarter caps
The adjustment is bounded. Difficulty may at most quadruple in a single retarget, and it may at most fall to one quarter of its previous value. The cap exists because the timestamps the rule reads are not trustworthy in the way the rest of the header is: they are asserted by miners, and the protocol only constrains them loosely, requiring each to exceed the median of the previous eleven and to stay within a window of the receiving node's own clock.
Without a cap, a miner who controlled a majority of hash rate could mine a retarget period's blocks with manipulated timestamps, drive the computed ratio to an extreme, and produce a difficulty so low that subsequent blocks became trivial to produce. The four-times ceiling and the one-quarter floor bound how much damage a single period of dishonest timestamps can do, at the cost of slowing the network's response to a genuine, very large change in hash rate.
The caps are rarely reached. In the ordinary course of events the adjustment is a few per cent in either direction, because hash rate changes gradually and the two-week sample is long. When they are reached, it is usually a sign of something unusual: a large mining operation going offline, a regulatory disruption in a major mining region, or the network recovering from a period in which blocks were found far faster than intended.
What the ten-minute target is for
The ten-minute interval is not a promise about confirmation speed. Blocks are found at random intervals around that mean, so a wait of twenty minutes between blocks is unremarkable and a pair of blocks found seconds apart is equally normal. What the target provides is a predictable rate of issuance and a predictable rate of confirmation over any long stretch, which is what lets the supply schedule be stated decades in advance.
It also paces the propagation of blocks. Ten minutes is generous relative to the time it takes a block to reach most of the network, so miners are usually building on the same tip rather than racing on competing branches. Shorten the interval and stale blocks become common, wasting work and weakening the incentive to mine honestly. Lengthen it and confirmations become slow enough to be impractical for ordinary payments.
The adjustment is therefore the mechanism that keeps the supply schedule honest. Without it, a rising hash rate would compress the interval and issue bitcoin faster than the schedule intends; a falling hash rate would stretch it and issue slower. The supply schedule page shows the issuance the rule is protecting, and the hashrate page explains the quantity the adjustment is responding to. The proof of work page covers the puzzle the difficulty parameterises.
Sources and references
- Bitcoin Optech, Difficulty adjustment, for the retarget interval, the adjustment formula and the four-times and one-quarter bounds as implemented.
- The Bitcoin Developer Reference for the target and difficulty encodings and the header fields the retarget reads.
- Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System, section 4, for the original statement of the ten-minute target and the retarget rule.
Related reading
- Protocol, Transactions & MiningThe supply schedule, transaction mechanics and mining economics behind the price.
- Proof of WorkThe hash puzzle, the target and nonce, and why accumulated work secures the chain.
- HashrateWhat hashrate measures, why it is estimated, and how it differs from difficulty.
- Mining PoolsPooled hash rate, share accounting, payout schemes and centralisation.
- Miner RevenueThe block subsidy plus fees, and how the mix changes across subsidy epochs.
- Mining EconomicsCapital and energy costs, break-even, hashprice and compressing margins.