Share Validation Guide for Bitcoin Solo Miners

Your miner can show thousands of accepted shares, then reject the next ten after a new block arrives. That is not automatically a fault. A share validation guide starts by separating normal timing from work your miner could not have submitted successfully.

For a solo miner, shares do not create a balance. They show whether the path from your rig to the pool is working. The one share that matters most is the rare one that also meets the Bitcoin network target. If that happens, the pool must read it correctly, build a valid block, and send it out before another block makes it old.

What a Share Actually Proves

Your rig receives a job. The job contains the material needed to build a candidate Bitcoin block header. Your rig changes the permitted fields, hashes the header, and submits results that are below the share target assigned to it.

That share target is usually much easier to meet than the network target. It gives the pool a regular way to check that the rig is receiving work and submitting results. A share accepted by the pool is not a Bitcoin block. It is evidence that the submitted header met the pool's assigned target for that job.

A found block is different. The same header must meet Bitcoin's current network target. Network difficulty sets the odds of that event at every pool. A pool cannot add luck to a rig. Solo mining is a lottery, and an average wait is not a schedule.

This distinction matters when reading a miner dashboard. A rejected ordinary share can identify a connection, job, or configuration problem. It does not mean a block reward was lost. A rejected network-target share would be far more serious, which is why the validation path deserves more attention than a green accepted-share counter.

Share Validation Guide: The Checks That Matter

A pool cannot validate a share by trusting the number displayed by firmware. It needs the bytes your rig submitted. It must match the submission to a job it issued, reconstruct the header under the rules for that job, hash it, and compare the result with the assigned share target.

The order matters. A pool first needs to know which job the share belongs to. It then checks that the submitted fields are allowed. Finally, it checks the hash. If the job is gone, the fields are malformed, or the hash misses the assigned target, the share should not be accepted.

A useful rejection reason tells you which of those checks failed. Firmware wording differs, but these are the common cases:

• Stale share: The rig submitted work for an older job after the pool moved to new work. A few can happen around a new block or during a brief connection delay. A continuing stream points to latency, a slow miner, or a connection that is not receiving job updates.
• Low-difficulty share: The submitted hash did not meet the target assigned to the rig. This can be normal at the edge of a device's reporting behavior, but frequent failures may indicate bad work construction or unstable hardware.
• Duplicate share: The pool already received the same result for the same job. Retries after a network interruption can cause this. Repeated duplicates can also come from two devices using overlapping work fields.
• Unknown or expired job: The pool cannot match the submission to active work. This often follows a reconnect, a long pause, or delayed traffic.
• Malformed submission: The message cannot be parsed or contains values that do not fit the job. This is a configuration or firmware compatibility issue, not bad luck.

The exact labels matter less than the pattern. One stale share when Bitcoin advances is ordinary. Hundreds of stale shares while the rig otherwise appears connected are a reason to inspect the route, the miner clock, and job-update behavior.

Difficulty Changes Can Look Like Errors

Pools adjust share difficulty so they can measure work without being buried in messages from faster rigs. Your device may receive a new difficulty and a new job close together. Work created under the old difficulty must be judged under the rules attached to that job, not the rules currently on screen.

That is why a validator needs job history for a short period. Dropping the old job the moment a new one is issued can turn valid in-flight shares into false stale rejections. Keeping old work forever would create a different problem: the pool could accept work that no longer belongs to a usable block template.

There is no universal number of seconds that fits every miner and connection. A rig far from the server has more round-trip delay. Distance changes how quickly new work reaches the rig. It does not change the chance of finding a block.

Check the Path From Your Rig First

Start with the miner's own log. Record the time of a reconnect, a difficulty change, a new job, and the first rejection after it. Do not diagnose a single line without the lines around it.

Next, compare accepted and rejected shares over a meaningful interval. A small number of stale shares during new-block transitions is different from a rejection rate that persists for an hour. If the pattern begins after a firmware update, test the previous configuration before blaming the pool.

Then check the connection settings. For Bitcoin on NexusPool (nexuspool.io), point the rig at solo.nexuspool.io:3350 and use the Bitcoin address that should receive a found block. The endpoint accepts Stratum V1 and encrypted Stratum V2 on the same port. No account or payout balance sits between a found block and that address.

Do not paste an exchange deposit address into a solo-mining configuration unless you accept the risk of its rules changing or its access being lost. A self-controlled Bitcoin address gives you a direct way to inspect the payout if a block is found.

If your rig supports encrypted Stratum V2, verify the published authority key before relying on encryption. Encryption protects the connection from observation and alteration in transit. It does not correct a wrong payout address entered at setup.

A Valid Share Is Not Yet a Valid Block

When a new Bitcoin block appears, miners need new work. Some pools can prepare a first job from the new header before their node finishes validating the block. That first job has no transactions. It exists to reduce time spent hashing on the prior block while validation completes.

The transaction-bearing job follows after validation. This creates a trade-off worth understanding. Early work can reduce old-template hashing, but it cannot promise that every first job becomes the final valid template. Your miner should accept new work promptly and stop submitting the old job when instructed.

If your rig finds a network-valid header, the pool has a different set of duties. It must preserve the submission, verify it against the network target, construct the block with the configured payout, and submit it to Bitcoin nodes. A share counter cannot prove that this happened.

For that check, inspect the block itself once it is known to the network. The coinbase transaction is the record. It shows the subsidy and transaction fees paid by that block, and it shows the output address. A Payout Preflight can show the miner that proposed payout on the current block before a find. The final block remains the authority.

What to Ask When a Rejection Looks Wrong

Ask for the job identifier, the assigned difficulty, the submitted values, and the stated rejection reason. Those facts let an operator reproduce the decision. “Invalid” without the relevant job and target is not enough to distinguish a bad share from a bad explanation.

For a small farm, also ask what happens after a quiet period. A difficulty change while rigs are offline can make their first returning shares harder to interpret. Holding a rig's difficulty for a short quiet period avoids needless adjustment churn when it comes back.

If a pool reports accepted shares, look for an independent record of counted work where one is offered. At NexusPool, an hourly signed receipt covers the work counted from one rig during that hour. A published signing key lets a miner check the signature with a BIP340-capable library. It is an accounting check, not a substitute for inspecting a found block.

The practical goal is not a perfect zero-reject screen. It is a system where ordinary timing has ordinary explanations, recurring failures leave enough evidence to trace, and a rare winning share has a verifiable route to the chain.

Trust nothing. Verify the rejection reason, the payout address, and the block when your rig finds one.