Set Per Rig Difficulty Without Losing Shares

A 500 GH/s Bitaxe and a 100 TH/s ASIC should not be forced to speak at the same pace. Set per rig difficulty correctly, and each miner submits shares often enough to prove it is working without turning your network, pool, or device into a share-counting exercise.

Share difficulty does not change Bitcoin’s network difficulty. It does not improve your odds of finding a block. It changes the target your miner must meet before it reports a share to the pool. That makes it an operational setting, not a luck setting.

What per-rig difficulty actually controls

A Bitcoin miner hashes candidate block headers. A valid block must fall below the current network target. A share is also a valid hash, but it only has to fall below the pool’s assigned share target. Because the share target is easier than the network target, miners find shares regularly even though blocks remain rare.

Difficulty is usually expressed relative to difficulty 1. Raise the assigned difficulty and the share target gets harder. The miner submits fewer shares. Lower it and the miner submits more. The underlying hash rate does not change either way.

This distinction matters most in solo and lottery mining. A miner that solves a valid Bitcoin block earns because it found a block, not because it accumulated a large number of low-difficulty shares. Shares let the pool validate that your miner received work and returned valid results. They are evidence of work. They are not extra entries that change the probability of a given hash solving a block.

A pool still needs a sensible share rate. If a low-hashrate miner is assigned difficulty that is too high, it may appear silent for long stretches. If a fast ASIC is assigned difficulty that is too low, it can produce a flood of shares that adds avoidable traffic and validation load.

Why set per rig difficulty instead of one global value

A mixed home fleet is normal. One shelf might hold an ESP32-class miner, a Bitaxe Gamma, and an older full-size ASIC. Their hash rates can differ by several orders of magnitude. One fixed difficulty is a compromise that usually fits none of them well.

Per-rig difficulty lets each worker receive a target appropriate to its actual output. The small device can report often enough for you to detect a dropped connection or a failed fan. The ASIC can report at a slower, manageable cadence. Neither needs to inherit a setting chosen for the other.

It also makes diagnosis cleaner. If a single worker stops submitting while the rest of the fleet continues, you have a specific problem to investigate: power, Wi-Fi, firmware, DNS, a bad cable, thermal throttling, or a rejected authorization. When every rig is buried in an unreasonable volume of shares, that signal gets harder to read.

Dynamic per-rig difficulty goes one step further. Rather than relying on a fixed estimate of hash rate, the pool observes a worker’s share cadence and adjusts its assigned target over time. At NexusPool, that means a small home miner and a standard Stratum V1 ASIC can be handled as individual workers rather than treated as one undifferentiated connection.

Dynamic assignment is not magic. A rig that has only just started, is aggressively overclocked, or is intermittently offline may need time before its observed rate settles. The correct behavior is adjustment based on evidence, not a promise that every worker will immediately land on a perfect number.

How to set per rig difficulty

Start by giving every physical miner its own worker name. Do not point ten devices at the same worker identity if you want useful rig-level visibility. A unique worker name gives the pool a separate record for each connection and gives you a clean place to compare reported and expected behavior.

Then check whether your pool uses automatic variable difficulty, manual difficulty, or both. If dynamic difficulty is available and your fleet has varied hardware, leave it enabled first. Let the system collect enough shares to estimate each rig. Manual overrides are most useful when you have a reason to control reporting behavior, such as constrained local networking, a device with limited processing headroom, or test hardware that changes speed frequently.

The practical target is a stable share interval. There is no universal number because a reasonable interval depends on pool design, connection quality, and how quickly you need an offline miner to become visible. Think in minutes, not milliseconds. A small miner that submits a share every few minutes provides usable evidence of life. A high-hashrate ASIC may reasonably submit less often at a higher assigned difficulty.

Do not chase a precise share count. Hashing is probabilistic. Even with a well-chosen target, a miner can go quiet longer than expected or submit several shares close together. One short gap is not proof of failure. Look for sustained deviation from the worker’s established pattern.

A simple way to estimate a starting point

If you need a manual setting, begin with the rig’s stable measured hash rate, not the number printed on a listing. Thermal limits, power settings, rejected shares, and network interruptions all affect the rate that reaches the pool.

Choose a reporting interval you can live with. A lower difficulty produces a shorter average interval. A higher difficulty produces a longer one. Make one moderate adjustment, wait for enough shares to observe the result, then adjust again only if necessary. Large changes made every few minutes create noise and teach you little.

If your miner reports locally in GH/s while another reports in TH/s, normalize before comparing them. One TH/s equals 1,000 GH/s. This sounds obvious until a manual setting intended for a 100 TH/s ASIC gets copied to a 500 GH/s device. That device may then wait a very long time for a share, even while hashing normally.

What difficulty cannot tell you

A healthy share rate does not prove every part of a mining operation is healthy. It does not prove that your payout address is correct. It does not prove a future block will be found. It does not establish that a pool will construct a block payout as claimed.

Likewise, a high number of shares does not mean your luck improved. Over a long enough interval, accepted share work should track delivered hash rate. Short intervals can look strange because mining variance is real. Nobody changes your luck. Us included.

For solo miners, this is why work accounting and payout construction should be checked separately. Confirm the address your miner authorizes with. Confirm accepted versus rejected shares. If a block is solved, verify the coinbase transaction and the on-chain destination. These are different claims with different evidence.

Common mistakes when tuning rig difficulty

The first mistake is using difficulty as a performance control. It is not a hash-rate setting. If your miner is slow, fix its clock, voltage, cooling, power supply, firmware, or network path. Lowering share difficulty may make it look more active, but it does not create hashes.

The second is treating every rejection as a difficulty problem. Rejections can come from stale work after a new block, late submissions, malformed shares, invalid shares, or connection instability. A modest stale rate can occur on any live network. A persistent rise deserves investigation. Check latency and packet loss before repeatedly changing difficulty.

The third is manually forcing the same value across unlike rigs. A uniform number feels organized, but it hides the actual goal: each worker should provide timely, valid evidence of its own work. Consistency in monitoring is useful. Artificial consistency in share targets is not.

Finally, do not confuse dashboard numbers with proof. A dashboard is an operator’s report. Your miner logs, the Stratum messages it receives, accepted-share behavior, and on-chain transactions are evidence you can compare against that report. The point of per-rig difficulty is not prettier statistics. It is a cleaner accounting trail from a specific machine to the work it submitted.

Set each worker up to report enough to be seen, but not so much that reporting becomes the job. Then verify what the pool accepted, what your miner sent, and where a solved block pays. Trust nothing. Verify your share accounting.