What Is Mining Difficulty?
The bar was never fixed
One-line recap, because M1 owns the search story: pulling a drawer fingerprints a card, and a fingerprint under the bar — the wall of leading zeros — is the find. What M1 didn’t say: the bar was never bolted down. When more hands pull, finds start landing early — so the network slides the bar toward zero, and only rarer fingerprints qualify. When hands leave, finds land late, and the bar slides back. Your machine never feels the slide directly; it pulls the same drawers per second either way. The only thing that changes is how rare a card has to be to count.
The thermostat: why difficulty rises — and genuinely falls
A thermostat doesn’t know how many people walked into the room; it reads one temperature and turns one dial. Difficulty is exactly that, for block pace. What it reads: how long the last stretch of blocks actually took, straight off the chain’s own timestamps. What it turns: the bar — formally, the target a fingerprint must land under. And nobody operates it: no committee, no vote per adjustment, no announcement — every node on Earth computes the identical new setting from the chain alone, which is the only way millions of strangers stay agreed on what counts as a find.
So “why does difficulty go up?” has a one-word answer: arrivals. Hands joined, finds came early, the thermostat noticed. And the dial genuinely turns both ways — this is no ratchet. Receipt from our own litecoind: at block 3,187,296, an epoch boundary, Litecoin’s difficulty stepped down 3.0% in a single move (replayed 2026-10-02). Hands had left, blocks had run late, and the bar slid back — commoner fingerprints qualified again, and the pace came home to schedule.
How the adjustment works: 2,016 blocks, then one decision
Bitcoin’s thermostat is deliberately slow. For 2,016 consecutive blocks — one difficulty epoch — the bar is frozen, whatever hashrate does. Plug a warehouse in mid-epoch and blocks simply arrive faster than 10 minutes until the boundary; unplug one and they arrive slower. At the boundary, every node runs the same arithmetic: did those 2,016 blocks take more or less than two weeks? The odd-looking count is that fortnight in disguise — 2,016 blocks × 10 minutes = exactly 14 days. Why two weeks and not two days or two months? The code states the arithmetic, not the reasoning; what a fortnight visibly buys — enough blocks to average out ordinary luck, few enough to track real change within weeks — is our observation, not anyone’s quoted intent.
expected = 2,016 × 600 s = 1,209,600 s · actual = what the chain’s timestamps recorded, clipped into [3.5 days, 56 days]
The clip is part of the formula, not a footnote: the measured timespan is clamped before the division (the retarget rule, from Bitcoin Core’s pow.cpp, fetched 2026-10-02), so a single adjustment is capped at ×4 upward and ×0.25 downward, however wild the epoch was. The protocol actually stores the update from the other end — new target = old × actual ÷ expected — the same dial turned from the opposite side; we untangle the two ends below. Here is one complete retarget, replayed from our own node’s block headers:
| One real retarget | own bitcoind, queried 2026-10-02 |
|---|---|
| Epoch measured | blocks 965,664 → 967,679 |
| Expected time | 1,209,600 s (exactly 14 days) |
| Actual time | 1,161,260 s (13 d 10 h 34 m) |
| Average gap | 1,161,260 s ÷ 2,015 gaps = 576.3 s |
| Rescale | 1,209,600 ÷ 1,161,260 = ×1.0416 — inside the clamp |
| Difficulty at block 967,680 | 127.45 T → 132.76 T (+4.16%) · 2026-09-19 07:09 UTC |
The observed jump (×1.041634) matches the formula to within the protocol’s compact rounding of the target (<0.001%). A completed retarget stays true forever — which is why this example is baked and dated, not live; the current epoch’s number is /btc/difficulty’s job.
One footnote the network has carried since 2009: the window measures first block to last — the 2,015 gaps between 2,016 blocks, not 2,016 of them — a tiny off-by-one in the original code, harmless, and by now seventeen years past fixing. It’s why the honest average above divides by 2,015.
A warehouse of new machines plugs in mid-epoch. What happens before the retarget?
Two thermostat designs: once an epoch, or every single block
Call Bitcoin’s design the slow thermostat: one reading per epoch, then commit for 2,016 blocks. Litecoin runs the identical design wound faster — the same 2,016-block count at 2.5-minute blocks, so its epoch lasts about 3.5 days instead of 14. Dogecoin threw the epoch out entirely: since block ~145,000 — March 2014, on our own node’s timestamps — its DigiShield rule re-computes the bar every single block. (Its first months used 240-block epochs — not Bitcoin’s 2,016, whatever some explainers claim.)
Why would a fast-block chain want the instant version? Because Dogecoin’s hashrate is mostly visiting: nearly all of it is Scrypt iron merge-mining it alongside Litecoin, and visitors can multiply — or vanish — overnight. Picture a surge driving a frozen-epoch bar way up, then leaving. The machines that remain face a bar set for a crowd that’s gone; blocks crawl; and since an epoch is counted in blocks, not days, slow blocks stretch the wait for relief in wall-clock time exactly when the chain can least afford it. The instant thermostat ends that wait in minutes. Receipt from our own dogecoind: blocks 6,398,000, 6,398,001 and 6,398,002 each carried a different difficulty — 43.8M, then 44.5M, then 46.9M (queried 2026-10-02). How hard DigiShield damps each move, and every other per-chain parameter, is /doge/difficulty’s territory; the concept worth keeping is that both designs are one thermostat at two sampling rates. Watch all three clocks run:
Epoch progress and block pace are the thermostat’s inputs, and inputs are all this tile shows — no projected adjustment, no direction. Publishing that estimate is the difficulty pages’ entire job, and the date of any next retarget is always an estimate. Dogecoin’s missing countdown is not a gap in our feed: under DigiShield there is nothing to count down to.
At the epoch boundary, what does a Bitcoin retarget actually compare?
Difficulty vs target: one dial, read from opposite ends
Three words tangle in every difficulty conversation; here is the untangling. The target (glossary) is the real object: the actual 256-bit threshold a block’s fingerprint must fall under — where the bar physically sits. Difficulty is a convenience ratio for humans: how many times harder the current target is than the easiest setting the chain ever had — difficulty 1, back at block 1. So the big number — 132.76 T, as of October 2026 (2026-10-02; this page’s one dated difficulty figure — the live one is a click away) — literally means 132.76 trillion times block-1 hardness. Same dial, opposite ends: when the target halves, difficulty doubles.
Difficulty also hands you the size of the search: expected pulls per find ≈ difficulty × 232 — about, because the easiest-ever target was written slightly under its round number, leaving the approximation ~0.0015% off. At the dated figure above, that’s roughly 5.7 × 1023 fingerprints per find, network-wide. And one precision note that makes the worked example click: the bar is a full 256-bit number, not a whole count of leading zeros. “Starts with N zeros” is shorthand — a +4.16% slide doesn’t wait for a new zero to appear; the threshold moves smoothly between them.
Difficulty goes up 4%. What did the target — the bar itself — just do?
What a rising bar does to your machine
The retarget lands and the bar sits 4.16% higher — what changed at your wall socket? Nothing. Your machine pulls the same drawers per second it pulled yesterday; the spec sheet is intact. What changed is the denominator of your luck: expected finds scale as 1 ÷ difficulty, so the worked example’s +4.16% mechanically trimmed every unchanged machine’s expected finds by about 4.0% (1 − 1 ÷ 1.0416). One receipt, no doom: that is the system working as designed — the thermostat defends the schedule, not any machine’s share of it. What the squeeze compounds to over a machine’s whole life — and why machines die economically before they die physically — is M2’s lifespan lesson; we won’t re-run its math here.
And the question this lesson has been stepping around: the thermostat responds to hands joining and leaving — so how does the network know how many hands are pulling? It doesn’t. Nothing in the protocol counts machines; no miner reports in. The network infers its own size backwards, from exactly the two things this page taught — where the bar sits, and how fast finds are landing. That inference — and why every hashrate chart on the internet disagrees with every other — is the next lesson.
Difficulty rises 5% and your machine doesn’t change. Your expected finds per day…
FAQ
- Why is a difficulty epoch 2,016 blocks?
- Because 2,016 blocks at the 10-minute target is exactly 14 days — the retarget simply asks whether the last 2,016 blocks took more or less than two weeks, and rescales. A window that long averages out ordinary luck; a window that short still tracks real hashrate change within weeks. Litecoin kept the same 2,016-block count at 2.5-minute blocks, so its epoch runs about 3.5 days; Dogecoin dropped epochs entirely and re-computes every block.
- What is the difference between difficulty and the target?
- The target is the actual threshold — the number a block’s fingerprint must fall under, i.e., where the bar physically sits. Difficulty is a convenience ratio: how many times harder the current target is than the easiest setting the chain ever had (difficulty 1, back at block 1). They are the same dial read from opposite ends: when the target halves, difficulty doubles. As of October 2026, Bitcoin’s ~132.76 T means 132.76 trillion times block-1 hardness.
- What would happen if difficulty never adjusted?
- Block pace would belong to the hardware instead of the protocol. Every warehouse of new machines would permanently speed blocks up — minutes, then seconds — and any large exit would leave the remaining machines grinding through hour-long gaps with no relief ever coming. The thermostat is what makes “a block about every 10 minutes” a property of the network rather than a coincidence of who happens to be plugged in.
- Does difficulty control how many new coins exist?
- No. Difficulty paces when blocks land; the subsidy schedule fixes how many coins each block mints. A difficulty change never changes the coins per block — that lever belongs to the halving schedule, which gets its own lesson at the end of this module.