Why pool vardiff can strand a slowing Bitcoin miner
Source report: 2026-09-18 · Editorial analysis published: 2026-09-19
Bitcoin Optech summarizes a controller failure mode: if difficulty changes only when a share arrives, a slowed miner may wait too long for the next share.
Analysis and practical implications
This section is our analysis and illustrative calculations, separate from the source report.
The vardiff deadlock
Bitcoin Optech Newsletter #423, published on 18 September 2026, summarizes Eric Price’s analysis of variable-difficulty controllers used by mining pools and proxies. A pool assigns a share target easier than Bitcoin’s network target so it can estimate each worker’s contribution. Vardiff raises or lowers that share difficulty to keep submissions near a chosen cadence. The failure appears when a miner suddenly slows: its old, high share difficulty remains, shares become rare, and a controller that recalculates only when a share arrives receives no event that tells it to lower difficulty.
Why tuning constants cannot solve it
Price’s core point is about observability rather than a poor proportional or integral constant. When a controller wakes only on a submitted share, silence contains information but the algorithm never processes it. Making the response more aggressive after a share may shorten recovery once one finally arrives, yet it cannot guarantee when that first share will occur. For an underclocked, overheated or partially failed worker, the wait can be much longer than the pool expects. During that interval, dashboards may show an irregular or apparently missing worker even though it still computes.
Timer-based recovery
The proposed remedy is to let elapsed time trigger a reduction. If no share arrives within a fixed interval, the controller lowers assigned difficulty so the worker can produce observable shares again. Optech notes that the Stratum v2 reference implementation already uses a timer, although recovery can still be slow on long-lived connections; ckpool recalculates on shares. Anthony Towns suggested locating this function at the last hop that still sees individual miners, such as a local Stratum v2 or DATUM gateway, and offered halving difficulty after thirty seconds without a share as an example rather than a universal setting.
Impact on accounting
Share difficulty does not change Bitcoin’s network difficulty and does not increase a machine’s physical hashrate. It changes the sampling rate used by the pool. Higher-difficulty shares arrive less often but represent more work; lower-difficulty shares arrive more often and represent less. Over a sufficiently long, stable period the estimator should converge. The stranded-miner case stretches the observation gap precisely when the worker’s rate has changed, making short-window monitoring poor and potentially delaying operational alarms. Payout impact depends on the pool’s accounting method, so operators should not infer lost revenue from a sparse chart alone.
How a farm can detect it
Compare three signals: the miner’s local rolling hashrate, accepted shares at the pool, and wall power. A large power or local-hash drop followed by a long absence of shares while the TCP connection remains open is a useful test case. Record assigned difficulty and its timestamps if the pool API exposes them. Check whether difficulty falls without a new share, how long recovery takes, and whether reconnecting immediately resets it. Reconnection is a diagnostic clue, not an ideal permanent remedy, because repeated reconnects can create load and hide the controller fault.
Testing without harming production
Use one worker or a staging proxy, not the whole farm. Price published a shaping proxy that drops a controlled fraction of shares so pool operators can observe how their controller reacts to an apparent slowdown. Any such test should be authorized, rate-limited and clearly labeled in monitoring, because deliberately dropping shares sacrifices measurable work. Capture controller logs, share timestamps, reconnects and assigned difficulty, then stop after the planned window. Never test against a third-party pool in a way that violates its terms or resembles abusive connection behavior.
Questions for pools and firmware teams
Pool operators should document whether vardiff has a no-share timer, its maximum recovery interval, how state survives reconnects and whether proxies aggregate multiple devices before control. Firmware and farm-management teams should expose both local hashrate and accepted-share timing, distinguish a connected worker from a productive one, and avoid alarms based on a single short window. Miners comparing pools can ask for vardiff behavior and worker-level telemetry alongside fee and payout method. The lesson is practical: absence of shares is itself a signal, and controllers must process time as well as arrivals.
Source: Bitcoin Optech ↗
Mining calculator ↗
