224 / 736SDIFF

Share Difficulty

Why a pool sometimes asks for fewer, harder results

Petra watches her mining machine. Its speed has not changed, yet the pool starts accepting fewer results. A pool brings miners’ work together and uses these results to check their contributions along the way. Before looking for a fault, Petra checks the assigned difficulty. Perhaps the machine has not slowed down: the pool simply requires rarer proofs of work and gives each one more weight.

Share Difficulty describes how demanding a mining result must be for a pool to accept it as a share—an ongoing proof of work. On average, higher difficulty means fewer qualifying results from the same number of attempts. This is a different setting from the difficulty of finding a Bitcoin network block.

Mining produces hashes: calculation results that can be read as numbers. To qualify for acceptance by the pool, a result must be no higher than the specified target. A lower target is stricter because fewer results fall below it. Share Difficulty therefore rises as the numerical target falls. For readers interested in the protocol, Stratum V2—the communication rules used with the pool—sends this limit in the target field of SetTarget. You do not need to know the message format to grasp the principle: a lower numerical ceiling makes the miner’s requirement harder. [1]

Imagine the pool raises Petra’s difficulty from 1024 to 2048. At the same hashrate—the number of calculation attempts per second—and with difficulty measured on the same scale, we expect roughly half as many qualifying results over an equal period. The machine keeps trying just as fast; fewer attempts pass the stricter filter. Individual intervals remain random. Petra should not expect every subsequent share to arrive after exactly twice the time. [2]

Counting messages alone would compare unlike things. Braiins therefore explains accounting in terms of work units weighted by difficulty. Two accepted results at difficulty 1024 have the same combined weight as one at difficulty 2048. Fewer messages do not prove a smaller contribution. Petra should not confuse this accounting weight with an exact count of calculations the machine actually performed: it is statistical evidence of work. Monetary rewards also depend on the pool’s rules. [3]

Changing Share Difficulty does not itself speed up the ASIC, the specialised chip in a mining machine. Nor does it change the network target for a Bitcoin block. With the same number of independent attempts and the same network difficulty, the chance of finding a block stays the same. The pool merely changes which results it wants to receive along the way. Lowering share difficulty does not make Bitcoin blocks easier to produce. [3]

Weaker and stronger machines would submit very different numbers of results under identical settings. VarDiff, automatic difficulty adjustment, balances this difference and reduces unnecessary traffic. Braiins also lets miners set a minimum. A minimum is a floor, not a fixed assignment: the pool may choose a higher difficulty based on hashrate. When Petra compares her settings with the current display, she first needs to establish whether she is reading the minimum or the actual assigned difficulty. [2]

Software needs to know which work a change applies to. Under the current Stratum V2 specification, SetTarget covers subsequently received jobs and previously received future jobs with an empty ntime_start. This field sets the initial timestamp in the block header, the short data summary of a block. An empty field marks a job that is still waiting to be activated. A previously received job with ntime_start already populated keeps its target stable. Investigating a rejection therefore requires more than comparing the result with the latest limit: it must be matched to the correct job. Mining software normally handles this. [1]

Petra may also encounter best share. Braiins Solo, for example, uses it for the highest-difficulty share found during a mining session. Assigned difficulty describes the requirement that qualified a result for submission; best share describes how rare the result actually found was. A record is not accumulated progress towards a block. Even an exceptional result does not improve the odds of the next independent attempt. [4]

Setting a manual minimum too high can make submissions so sparse that the hashrate estimate fluctuates widely. Monitoring may then raise an alarm even while the ASIC is still working. A brief interval without a share does not itself establish a fault. Petra compares assigned difficulty, observation period, accepted work and connection status. Together, these help her distinguish ordinary randomness from a real problem. [2]

For the clearest picture, read this entry together with Mining Share, Mining Target, Hashrate, Mining Pool, Bitcoin. The reverse links also lead from Mining Pool, Stratum V1, Stratum V2, Mining Share.

DOC · 001Stratum V2 — SetTarget and mining channelsSpecification DOC · 002Braiins Academy — Worker management and VarDiffDocumentation DOC · 003Braiins Academy — Pool work accountingDocumentation DOC · 004Braiins Academy — Best shareDocumentation
Revised: Source-first · No investment advice