Some Bitcoin mining controllers that manage variable difficulty can keep serving work calibrated to a machine's former speed after the rig cuts its hashrate. The miner may continue hashing and consuming electricity while its accepted shares become vanishingly rare.

Bitcoin Optech, an industry resource for sharing technical knowledge across Bitcoin companies, 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 rather than Bitcoin's network difficulty, and it describes a testable controller weakness rather than evidence of widespread miner losses.

How vardiff gets stuck

Mining pools assign each connection a share difficulty is easier than Bitcoin's block difficulty; a higher assigned difficulty corresponds to a harder share target. Submitted shares let the pool estimate a miner's hashrate and account for contributed work, while a variable-difficulty (vardiff) controller adjusts the assignment to keep shares arriving at a useful rate.

Price's analysis describes a trap that opens after a miner slows sharply. If the controller recalculates only when a share arrives, the old, harder assignment makes the next share less likely to appear. With no fresh share to trigger an update, the controller can hold the wrong difficulty, keeping the share stream sparse.

Why curtailment makes the flaw realistic

Abrupt curtailment is operationally realistic: mining sites throttle machines to draw less power, typically when the grid is under stress, which is exactly the hashrate cut this flaw responds to. During a January 2026 U.S. winter storm, CryptoSlate reported a sharp network hashrate drop as miners reduced power use, though that 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. Pay-per-share pays a fixed rate for each accepted share whether or not the pool finds a block, while proportional divides each reward window among the shares submitted during it. The risk appears in the realized window: if no accepted share arrives, a pay-per-share miner receives no payment for that interval, and if a few arrive, they remain payable. Under proportional, missing shares can increase other participants' portion of the reward window.

Stratum V2 mitigates, ckpool cited

Stratum V2 is the successor to the original Stratum protocol that pools use to distribute work and collect miners' shares. The current Stratum V2 reference implementation avoids a permanent freeze by recalculating on a timer and lowering difficulty during a share drought, though the analysis says recovery can still be slow on long-lived channels. That timer behavior belongs to the reference implementation, not to every deployment the Stratum V2 protocol permits. 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.

How operators can test it

Operators can now test the behavior directly. MARA Foundation's open-source shape-proxy acknowledges shares locally while forwarding a controlled fraction upstream, and 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 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. Until broader measurements exist, operator-run tests like these are the main route from analysis to evidence about prevalence.

Source: CryptoNewsNet