Rejected Mining Shares: Four Checks for Rates and Accepted Work

1. Read the rejection type and counter definition

The ViaBTC explanation of rejected shares distinguishes late work for old jobs, invalid results, duplicates and configuration issues. Labels can differ across software. Preserve the exact code and message rather than converting every rejection into a conclusion about chip failure.

Connection or authorization failures can prevent contribution before a submitted-share counter records anything. Determine whether a percentage includes stale results, separates them or weights results by difficulty. A local total since restart and a rolling pool window can legitimately differ even when the worker name is identical.

A brief spike does not prove stolen work or equipment collapse. A small sample, connection event or difficulty change may be relevant. Conversely, a persistent discrepancy deserves investigation even if the local hashrate display remains high. Establish what was not credited, when it occurred and how much work it represents.

Define the denominator before judging the percentage

If a pool receives 1,000 submissions, accepts 990 and rejects ten, the rejection proportion is 1%. If the display instead shows 1,000 accepted and ten rejected, the total is 1,010 and the proportion is approximately 0.9901%. Rejected divided by accepted answers a different ratio from rejected divided by total.

One rejection among ten results is 10%, but its evidence base is much smaller than one hundred among one thousand. Keep counts and duration beside percentages. Observe whether a discrepancy persists as the sample grows under comparable conditions instead of selecting a short window because it supports a preferred interpretation.

When combining intervals, add comparable counts or work first and calculate the overall proportion. One rejection out of ten followed by zero out of 990 gives one out of 1,000, or 0.1%. The simple average of the two interval percentages would be 5%, incorrectly giving unequal samples equal weight.

Difficulty weighting can change the answer

Imagine ninety accepted results at difficulty one and ten rejected results at difficulty ten. The count-based rejection proportion is 10%, while rejected relative work is 100 out of 190, approximately 52.63%. This fictional example shows why message counts and work weights are different measurements, not how every dashboard defines its metric.

Check whether a service already reports weighted units before applying difficulty again. Reweighting an already weighted counter duplicates the effect. If difficulty changed during the day, group results appropriately or use the service’s documented work measures. The last observed difficulty does not necessarily apply to all preceding submissions.

2. Match worker, time and connection path

Keep the worker identifier, server and observation boundaries. A miner that switched to a backup pool may have spent part of its uptime contributing elsewhere. Comparing its full local day with only one pool’s record can create a gap unrelated to rejected work. Likewise, a fleet total cannot be directly compared with one device.

Use a consistent timezone when relating network events to device messages. A rejection increase after reconnection provides a timing clue, not a complete diagnosis. Record precise timestamps and repeated events where available. That gives support a window to examine rather than an unspecific report that the problem happens sometimes.

If several devices change together, examine shared servers, network events and centrally changed settings. If one device differs, inspect its own records as well. This narrows the scope of investigation without proving that a shared or individual component is responsible. Differences in software and conditions can overlap.

3. Separate local output, accepted work and energy

A device can produce local work that the pool does not credit. The Braiins hashrate specification explains that pool-side estimates are inferred from received qualifying work and vary with the sampling window. A short difference between two rate displays is not automatically the rejection percentage.

In a simplified matched-period example, 200 TH/s local output with 98% of homogeneous work accepted corresponds to 196 TH/s accepted contribution. A separate case with 210 TH/s local output and 90% acceptance gives 189 TH/s. The higher local number produces less accepted contribution in that example.

These are conditional calculations, not recommended device settings. Energy can still be consumed producing rejected work, but a count-based rejection percentage should not automatically be multiplied by electricity if difficulty weighting or uptime differs. Compare measured energy and accepted work over matching intervals when evaluating economic efficiency.

4. Test one documented change at a time

First review server, port, algorithm, worker name and supported software against official pool and manufacturer instructions. Avoid configuration files or firmware copied from unknown comments. If settings are correct but the discrepancy remains, define a limited comparison with a saved previous state and a supported route back.

Changing server, firmware, frequency and cooling together makes it difficult to identify what changed the outcome. Specify the measurement and comparison duration first. Work involving electrical circuits, power supplies or protection systems requires the relevant procedures and qualified assistance rather than an improvised software experiment.

A reduction after reverting a recent supported setting can justify further comparison, but timing alone is not conclusive. Conditions may also differ. A short zero-rejection sample does not establish a permanent solution or prove that energy use, accepted output and stability all improved.

Evaluate results and prepare a useful support record

Preserve before-and-after duration, accepted and rejected work, reason codes, energy and downtime. If the percentage falls while accepted contribution falls sharply, that does not establish economic success. Compare categories separately: duplicates might disappear while stale results remain, meaning only part of the issue changed.

Keep model, firmware, algorithm, nonsecret configuration, timestamps and error details for official support. Remove credentials, wallet keys and access tokens, and avoid giving unknown parties remote control to repair a counter. A useful finding names the uncredited work, amount, period and associated changes while clearly identifying what remains unresolved.

Continue reading