Per-block difficulty retargeting: why 2,016 blocks is too slow for a small chain

Q: Why is Bitcoin's difficulty adjustment bad for a small chain?

Bitcoin retargets once every 2,016 blocks and clamps each change to a factor of four. That assumes hashrate changes slowly. A small SHA-256 chain shares hardware with Bitcoin, so its hashrate can rise or fall a thousandfold within minutes; the chain then either stalls for days after hashrate leaves, or is trivially reorganised while difficulty is far below the hashrate present.

Q: What is the difference between DGW and LWMA?

Dark Gravity Wave v3 averages the targets of the last 24 blocks and clamps the measured timespan to between one third and three times the expected value. LWMA takes a linearly weighted moving average of recent solve times, so the newest blocks count most, and it recommends clamping individual solve times and enforcing a tight future-time limit. LWMA reacts faster and is generally preferred for very small chains, but its author warns that a window that is too large causes oscillation.

Q: Does per-block retargeting stop 51% attacks?

No. It raises the cost of a short rented attack by making the difficulty rise within a few blocks, so the attacker has to sustain the hashrate rather than burst it. A determined attacker who rents enough hashrate for long enough can still reorganise the chain. Depth-based finality, checkpoints and minimum chain work address what retargeting cannot.

Q: What is a timewarp attack?

A miner with a majority of hashrate sets block timestamps far in the future, or backwards, so a difficulty algorithm that reads solve times from timestamps believes blocks are slow and lowers difficulty. Algorithms defend against it with a future-time limit, median-time-past rules, and clamps on individual solve times; per-block algorithms are more exposed because every block moves difficulty.

By Glenn Lyvers, Instant Access · Published 13 September 2026 · Updated 13 September 2026 · ~10 min read

01 What Bitcoin's rule actually does

The logic is short and it is in src/pow.cpp. GetNextWorkRequired() checks whether the next height is a multiple of DifficultyAdjustmentInterval() — 2,016 blocks, the 14-day nPowTargetTimespan divided by the 600-second nPowTargetSpacing. If it is not, the function returns the previous block's nBits unchanged: the comment reads “Only change once per difficulty adjustment interval”. If it is, CalculateNextWorkRequired() measures how long the last 2,016 blocks took, clamps that to no less than a quarter and no more than four times the target timespan, and scales the target proportionally.

Two properties follow. Difficulty is a step function that moves at most once a fortnight. And a single step can move it by at most 4× in either direction, so recovering from a 16× overshoot takes two full periods. On Bitcoin, where global hashrate rarely moves more than a few percent in a fortnight, both properties are harmless and the simplicity is a virtue. Testnet has a special case — fPowAllowMinDifficultyBlocks lets anyone mine a minimum-difficulty block after twenty minutes of silence — which is a tacit admission that the mainnet rule does not work when hashrate is small and fickle.

02 Why it fails a small chain

A new SHA-256 chain shares hardware with Bitcoin. Every ASIC that mines Bitcoin can mine it, and marketplaces exist to rent that hashrate by the hour. Suppose the chain is running at 1 PH/s and a miner points 1 EH/s at it — a thousandfold increase, and a rounding error against Bitcoin's network. With Bitcoin's rule, nothing happens to difficulty until 2,016 blocks have been found, which at a thousand times the intended speed takes about twenty minutes instead of two weeks. The miner collects two weeks' worth of block subsidy in twenty minutes, difficulty then rises — by the maximum 4×, not 1000×, because of the clamp — and the miner leaves.

Now the chain is at 4× its previous difficulty with its original 1 PH/s. Blocks that should take 30 seconds take two minutes, and the next retarget is 2,016 blocks away: about three days at that pace, and the correction is again capped at 4×. If the burst happened twice, the honest chain is stuck for weeks. That is the stall failure. The reorg failure is the mirror image: while difficulty is far below the hashrate present, an attacker can mine a private chain faster than the public one at almost no cost and publish it deep enough to reverse settled transactions. Both failures come from the same fact: difficulty is a lagging estimate of hashrate, and the lag is two weeks.

Why the clamp makes it worse The 4× clamp exists to stop a single bad period from wrecking difficulty on Bitcoin. On a small chain it guarantees that difficulty cannot follow a large hashrate step in one period, so the chain is mis-priced for several periods in a row — exactly the window an attacker wants.

03 The algorithms that replaced it

Every altcoin that survived its first year on shared hardware replaced the 2,016-block rule with something that adjusts every block from a short window. The lineage, with the values as they appear in the reference implementations:

Per-block difficulty algorithms — reference values
Algorithm	Origin	Window	How it estimates hashrate	Clamp
Kimoto Gravity Well (KGW)	Megacoin, 2013	Variable: `PastBlocksMin` to `PastBlocksMax`, derived from the target timespan	Averages past difficulty over a window that grows until the measured rate deviates from an “event horizon” curve	Implicit in the horizon function
DigiShield	DigiByte, 2014; adopted by Dogecoin	1 block	Measures the last solve time against target, then damps the change: `nModulatedTimespan = retargetTimespan + (nActualTimespan − retargetTimespan) / 8`	Between `retargetTimespan − ¼` and `retargetTimespan + ½` (i.e. −25% / +50% per block)
Dark Gravity Wave v3 (DGW)	Dash (Evan Duffield), 2014	24 blocks (`nPastBlocks = 24`)	Running average of the last 24 block targets, scaled by measured vs expected timespan	Timespan clamped to ⅓× … 3× expected
LWMA	Zawy (zawy12), 2017–18	N blocks; N = 60 typical for 10-minute targets, larger N for shorter targets	`next_difficulty = average(difficulties) × T / LWMA(solvetimes)`, with recent solve times weighted linearly higher	Each solve time capped at `6 × T`; out-of-order timestamps replaced with `previous + 1`
ASERT (aserti3-2d)	Bitcoin Cash, November 2020	None — exponential decay from an anchor block	`target = anchor_target × 2^((time_delta − ideal_block_time × (height_delta + 1)) / halflife)`	Continuous; half-life 172,800 s (two days) sets the response speed

The trend across this list is from clever to boring. KGW's variable window and event-horizon curve were replaced by DGW's plain average, which was in turn replaced by LWMA's plain weighted average, and Bitcoin Cash eventually moved to a closed-form exponential with no window at all. Each step removed a way the previous algorithm could be gamed or made to oscillate.

04 How each one breaks

Timestamp manipulation

All of these algorithms read solve times from block timestamps, and block timestamps are set by miners. A miner with a majority of hashrate can claim blocks took longer than they did — by setting timestamps in the future up to the network's future-time limit — and the algorithm will lower difficulty in response. This is the timewarp family of attacks. The defences are a tight future-time limit (FTL), median-time-past ordering, and clamping individual solve times; LWMA's documentation recommends an FTL of N × T / 20 and warns that cutting the FTL below about 125% of a node's clock-reversion rule “will allow a 33% Sybil attack on your nodes”. Bitcoin's own timewarp exposure was reduced by BIP94 in 2024 (testnet4), and Bitcoin Core v29 carries an enforce_BIP94 consensus flag for exactly this reason.

Oscillation

A fast algorithm on a chain with a few large miners overshoots. Hashrate arrives, difficulty spikes, hashrate leaves because the spike made it unprofitable, difficulty collapses, hashrate returns. KGW was notorious for it; DGW's 24-block average and its ⅓×/3× clamp were the fix. LWMA's author is explicit that “the size of an algorithm's averaging window of N blocks is more important than the particular algorithm”, and that excessively large N on a small coin produces oscillations and multi-day block delays. ASERT was adopted on Bitcoin Cash specifically to remove the oscillation and the switching incentive that its previous 144-block algorithm produced.

Hash-rate switching

Whatever the algorithm, a miner who can move between two chains at will can mine the one whose difficulty is lagging below its true hashrate, and leave when it catches up. Faster algorithms shrink that window; none close it. The residual profit of a rental burst is roughly the block subsidy earned during the algorithm's response time, so the aim of the design is to make that response time a handful of blocks.

05 Spearmint's ADR

Spearmint's block target is 30 seconds, twenty times Bitcoin's frequency, which makes the arithmetic in section 02 twenty times worse under Bitcoin's rule and makes a per-block algorithm mandatory rather than optional. Aggressive Difficulty Retargeting (ADR) recalculates the target every block from a short window of recent solve times, so that a step change in hashrate meets a difficulty that has risen to match it within blocks rather than periods. The overview describes the intent; the economic policy fixes the block target and reward the algorithm must serve.

What the project does not claim is that ADR is solved. The October 2025 comparison meeting recorded oscillation risk and extreme step changes as open modelling questions, not answers. The September 2026 review then added a sharper concern: with AI-assisted planning tools, an attacker can model the retarget response and time a rental to the exact windows where it is weakest, so the adversarial simulations now run against planned hashrate schedules, not just random volatility. The parameter ranges — window length, weighting, clamps, future-time limit — are what those simulations are meant to settle, and the meeting notes say plainly that the answer may change the values published in the policy.

What a node operator enforces ADR is a consensus rule: every node running Spearmint Core computes the same target from the same window and rejects blocks that do not meet it. Running your own node (how) means you are checking the retarget rather than trusting a pool's view of it.

06 What retargeting cannot fix

Difficulty adjustment changes the price of a hashrate attack; it does not change whether one is possible. An attacker who rents enough hashrate and sustains it for long enough will out-work an honest chain of any difficulty. Three other mechanisms address that, and Spearmint uses all three:

Depth-based finality (DBF). Confirmation depth scales with transaction value, so a reorg deep enough to reverse a high-value settlement must be sustained across many blocks, not a burst. Described on the overview.
Checkpoints. Block hashes hard-coded in chainparams.cpp that any competing history must contain. Spearmint plans to pin the pre-launch acquisition range this way in its first public release (transparency).
nMinimumChainWork. A node rejects any chain with less cumulative work than the value in its release, so a privately mined competitor from genesis cannot replace published history.

None of these is novel and none is free of trade-offs; checkpoints in particular are a form of developer trust. The point of listing them is that a fast difficulty algorithm is the first layer, not the last, and a chain that advertises only its retargeting has not finished thinking about the problem.

07 Key takeaways

Bitcoin retargets every 2,016 blocks with a 4× clamp; on a chain that shares ASICs with Bitcoin, that lag is measured in weeks and the clamp guarantees under-correction.
A hashrate burst under Bitcoin's rule yields two weeks of subsidy in minutes, then leaves the honest chain stalled at the wrong difficulty.
KGW, DigiShield, DGW, LWMA and ASERT all adjust per block from a short window; the trend is toward simpler formulas because clever ones oscillate or get gamed.
Every timestamp-based algorithm is exposed to timewarp; defend with a tight future-time limit, median-time-past, and solve-time clamps.
Spearmint's ADR is per-block by necessity at a 30-second target; its parameters are being settled by adversarial simulation and the team records the oscillation risk as open.
Retargeting prices an attack; it does not prevent one. Depth-based finality, checkpoints and minimum chain work do the rest.

08 Questions

Why is Bitcoin's difficulty adjustment bad for a small chain?

It retargets every 2,016 blocks and clamps each change to 4×, which assumes hashrate that moves slowly. A small SHA-256 chain's hashrate can move a thousandfold in minutes because the hardware is shared with Bitcoin and rentable by the hour. The chain either stalls after hashrate leaves or is cheaply reorganised while difficulty lags below the hashrate present.

What is the difference between DGW and LWMA?

DGW v3 averages the targets of the last 24 blocks and clamps the measured timespan to ⅓×–3× the expected value. LWMA takes a linearly weighted moving average of recent solve times so the newest blocks count most, caps each solve time at 6× the target, and pairs that with a strict future-time limit. LWMA reacts faster and is the usual choice for very small chains; its author warns that too large a window causes oscillation.

Does per-block retargeting stop 51% attacks?

No. It raises the cost of a short rented attack by making difficulty catch up within a few blocks, so the attacker must sustain hashrate rather than burst it. Enough hashrate for long enough still wins. Depth-based finality, checkpoints and minimum chain work address what retargeting cannot.

What is a timewarp attack?

A majority miner sets block timestamps forward (or out of order) so a timestamp-driven algorithm believes blocks are slow and lowers difficulty. Defences are a tight future-time limit, median-time-past ordering, and clamping individual solve times. Per-block algorithms are more exposed because every block moves difficulty, which is why LWMA's documentation spends so much space on FTL.

Run a Spearmint Core node How to fork Bitcoin Core v29 Economic policy

09 Sources

Bitcoin Core v29.0, src/pow.cpp — github.com/bitcoin/bitcoin/blob/v29.0/src/pow.cpp (GetNextWorkRequired, the ¼×/4× clamp, fPowAllowMinDifficultyBlocks).
Bitcoin Core v29.0, src/kernel/chainparams.cpp — github.com/bitcoin/bitcoin/blob/v29.0/src/kernel/chainparams.cpp (nPowTargetTimespan = 1209600, nPowTargetSpacing = 600, enforce_BIP94).
Dash Core, src/pow.cpp — github.com/dashpay/dash/blob/master/src/pow.cpp (DarkGravityWave, nPastBlocks = 24, ⅓×/3× clamp; KimotoGravityWell).
Dogecoin Core, src/dogecoin.cpp — github.com/dogecoin/dogecoin/blob/master/src/dogecoin.cpp (CalculateDogecoinNextWorkRequired, DigiShield modulation and bounds).
Zawy, “LWMA difficulty algorithm” — github.com/zawy12/difficulty-algorithms/issues/3 (formula, solve-time cap, FTL guidance, oscillation warning).
Bitcoin Cash Node, ASERT (aserti3-2d) upgrade specification, November 2020 — gitlab.com/bitcoin-cash-node/…/2020-11-15-asert.md.
BIP94, “Testnet 4” (timewarp mitigation) — github.com/bitcoin/bips/blob/master/bip-0094.mediawiki.
Spearmint meeting notes, October 2025 and September 2026 — oct25-meeting.html#risk, sep11-meeting.html#concerns.