Follow the decisions · Accounting for mining work
The Miner Slowed Down, but the Pool Kept Expecting the Old Speed
A pool estimates a miner's work from the shares it receives. When the machine slows abruptly, an excessive share difficulty makes those shares rare—and the signal needed for correction begins to disappear.
EDITORIAL OVERVIEW · Prepared by the project editors from the sources listed below.
Why a pool needs shares
A mining pool cannot simply trust a device's claim about its hashrate. The miner regularly submits shares: proofs of work that are not difficult enough to become Bitcoin blocks but do demonstrate completed computation.
To receive results at a useful rate from both large and small machines, a pool assigns a share difficulty to each connection. Variable difficulty, or vardiff, raises it when shares arrive too quickly and lowers it when they arrive too slowly.
The disappearing signal
Suppose a miner slows because of heat, a power limit, equipment trouble, or participation in a grid demand-response program. The pool still expects its former performance and the assigned difficulty remains high.
The pool needs new shares to observe the slowdown and lower the difficulty. Yet the excessive difficulty is precisely what makes those shares rare. A controller that recalculates only when another share arrives can remain stuck at the wrong value for a long time.
Why tuning alone is not enough
An operator can change the controller's sensitivity, step size, or averaging interval. Those parameters only determine how it reacts to received data. When no shares arrive, there is nothing to process.
Depending on the pool's reward system, the miner may receive less than expected and the missing contribution may be redistributed among other participants. To the pool, a working but slowed miner can resemble one that simply disconnected.
A clock instead of waiting
The proposed remedy is to lower difficulty not only after receiving a share but also on a timer. If the miner remains quiet, the controller gradually eases the task. When shares return, ordinary feedback refines the appropriate value.
The Stratum V2 reference implementation already performs periodic recalculation. The research also proposes testing pools with a proxy that deliberately hides some shares: a safe controller should eventually lower the assigned difficulty on its own.
This does not change Bitcoin's consensus rules or undermine proof of work. It concerns the software between an individual miner and a pool, where a missing signal can itself preserve an incorrect state.
A miner can keep hashing while its accounting system stops hearing it because the system is still waiting for the old rhythm.
Sources and verification
Technical material about mining-pool accounting. The economic effect depends on the controller implementation and the pool's reward scheme.
Unless stated otherwise, the text, conclusions, structure and editorial arrangement were created by the project editors. Facts, quotations and source materials remain attributable to their authors and rights holders.
← Back to the rubric