Some Bitcoin mining vardiff (variable difficulty) controllers can keep demanding work calibrated for a machine’s former speed after it cuts hashrate. The miner can keep hashing and consuming electricity while accepted shares become vanishingly rare.
Bitcoin Optech highlighted the failure mode on Sept. 18, drawing wider attention to an analysis that mining engineer Eric Price published in July. The finding concerns pool-assigned share difficulty, not Bitcoin’s network difficulty, and it describes a testable controller weakness rather than evidence of widespread miner losses.
How Bitcoin mining vardiff gets stuck
Pools assign each connection a share difficulty that is easier than Bitcoin’s block difficulty. A higher assigned difficulty corresponds to a harder share target. The submitted shares let the pool estimate hashrate and account for contributed work, while a variable-difficulty, or vardiff, controller adjusts the assignment to keep shares arriving at a useful rate.
Price’s controller analysis describes a trap after a miner slows sharply. If the controller recalculates only when a share arrives, the old, harder assignment makes the next share less likely. With no fresh share to trigger an update, the controller can hold the wrong difficulty, which keeps the share stream sparse.
Abrupt curtailment is operationally realistic. During a January 2026 U.S. winter storm, CryptoSlate reported a sharp network hashrate drop as miners reduced power use. The event was not linked to a vardiff loss.
A high share difficulty does not automatically erase a miner’s expected credit over a long period. Pools can give a rare high-difficulty proof more accounting weight, as Braiins’ pool documentation explains. The risk appears in the realized window: if no accepted share arrives, a pay-per-share miner receives no payment for that interval; if a few arrive, they remain payable. Under proportional accounting, missing shares can increase other participants’ portion of the reward window.
The current Stratum V2 reference implementation avoids a permanent freeze by recalculating on a timer and lowering difficulty during a share drought. The analysis says recovery can still be slow on long-lived channels. That timer behavior belongs to the reference implementation, not to every deployment permitted by the Stratum V2 protocol.
The analysis and Optech identify ckpool as a deployed share-triggered example. How common the behavior is, and whether it has caused material real-world losses, has not been measured by the available sources.
Operators can now test the behavior directly. MARA Foundation’s open-source shape-proxy acknowledges shares locally while forwarding a controlled fraction upstream. Step, ramp and stall profiles can make the pool see an apparent decline without changing the miner’s physical output.
A falling assigned difficulty shows that the tested controller has a recovery path. A target that stays pinned is evidence of slow or absent recovery under that profile and observation window, though timer cadence, channel age and random share arrival can affect the result.
