SoloMining.xyz
English
English简体中文FrançaisРусскийEspañolDeutsch日本語한국어
Check a wallet

Rejected shares

Diagnose Bitcoin Share Rejections

Separate a connection or authorization failure from work that arrived late, was duplicated or missed the pool's share target. Follow the response reason and job context; a rejection percentage alone cannot identify the cause or quantify lost block probability.

Find the next check for your symptom

Record the installed firmware, endpoint, UTC time, assigned share difficulty and exact response where available. These checks guide your next step; they do not remotely diagnose hardware or recover a reason the miner did not expose.

Choose a symptom, then follow the checks in order. This guide does not inspect your miner or infer an error reason from a rejection percentage.

Cannot connect to the pool

Start with the connection path. No accepted share is expected until the miner is connected, authorized and receiving work.

  1. Match host, port and TCP/TLS. Keep the protocol prefix out of a separate host field.
  2. Read the device log for DNS, timeout or TLS messages. Check the specific network rule involved instead of disabling all protections.
  3. Confirm that the miner receives a job after authorization. Save the current settings before trying another endpoint.
Connected, but no accepted shares

Connected is only one stage. The miner still needs valid work and a result meeting the assigned share target.

  1. Check authorization and incoming jobs in the device log; check that hashing is running.
  2. Read the assigned share difficulty. Use the waiting-time tool below to understand why low hashrate may produce sparse feedback.
  3. Check the actual response to a submitted share. An error needs its own branch; waiting longer cannot fix a rejected address.
Accepted shares, but no pool stats

Separate the miner's result from the dashboard update. A delayed or unavailable telemetry feed does not, by itself, prove the miner has stopped.

  1. Compare the complete wallet address and worker name with the settings on the miner.
  2. Check the last accepted-share timestamp and the dashboard time window, not just an old total.
  3. If the device continues to receive accepted responses, record those times and contact support about the missing telemetry.
Stale or expired-job responses

Work may refer to a job that is no longer accepted. Investigate job updates and connectivity; a single ping measurement does not identify the cause.

  1. Record the exact response and when it happened, including any reconnect or new-job message.
  2. Compare connection stability without changing voltage, frequency and pool at the same time.
  3. Check whether firmware and pool logs describe the same job. Ask support if the reason is absent or ambiguous.
Duplicate or low-difficulty responses

These reasons are different from stale work. A duplicate submission count is not automatically the same fraction of lost hashing time.

  1. For duplicates, inspect repeated job and nonce submissions and reconnect behavior.
  2. For low difficulty, compare the miner's assigned target with the submitted result and the firmware's difficulty handling.
  3. Do not copy another pool's password difficulty syntax without checking support. Keep a short, redacted log sample for the operator.
Pool hashrate differs from the miner

Pool hashrate is an estimate from submitted work. Device estimates and short pool windows can vary, especially with sparse shares.

  1. Compare the same time window and allow enough accepted work for the estimate to settle.
  2. Record assigned difficulty, interruptions and any actual rejection reasons alongside the hashrate.
  3. A higher best share or raw share count after switching pools is not evidence that each hash now has better block odds.

Understand the wait for a share

At steady hashrate and fixed share difficulty: average seconds ≈ difficulty × 2³² ÷ hashes per second. Individual waits vary; this is not a connection timeout or a block estimate.

Prepare a privacy-checked issue summary

Support report

Prepare a privacy-checked issue summary

Create a report in this browser, then choose how to contact support. Nothing is uploaded or sent automatically.

Use the UTC times that cover the issue.

The tool masks common Bitcoin addresses, email addresses, IPv4 addresses, and obvious secret/password/token/seed/private-key lines. It cannot find every sensitive value. Review the report yourself before sharing it.

A share is feedback, not progress toward a block

Pool share difficulty sets a threshold for reporting work. Raising it can reduce the number of reported shares without changing the Bitcoin network target. This is why counts from two pools are not directly comparable. Use accepted work, time windows and error reasons to judge operation, while treating a best-difficulty record as a past result.

  • Do not tune for the largest share counter.
  • Do not treat Best Difficulty as a percentage-complete meter.
  • Keep share difficulty separate from network difficulty in any estimate.

Map the response to one next check

Pool wording varies. Stale or expired work: compare the job and response timestamps with the latest work update. Duplicate: inspect reconnect, retry and worker-session messages for repeated submissions. Low difficulty or below target: compare the reported share target with the difficulty assigned by the pool and supported by the firmware. Unauthorized or invalid user: recheck the address, worker suffix, password field and transport format. These are error categories, not a universal code table; ask the pool operator when the response is ambiguous.

  • Match a stale response to job-change and reconnect timestamps.
  • Compare a low-difficulty response with the pool's assigned target and the device's displayed difficulty.
  • Verify the Bitcoin address and worker syntax after an authorization error; redact the address before sharing logs.
  • Change one relevant setting at a time; a rejection percentage is not a direct estimate of lost block probability.

Check the original guidance: ESP-Miner / AxeOS · GitHub · Bitcoin Developer Guide · CKPool FAQ

Compare telemetry over matching windows

A miner's instantaneous estimate and a pool's estimate from reported work need not match in a short window. Sparse high-difficulty shares increase that variation. Look for recent accepted responses, the correct worker and the same period before inferring a fault. Missing data should remain unavailable rather than being silently read as zero work.

  • Compare worker-level observations before combining several machines.
  • Note outages and settings changes inside the comparison window.
  • If accepted responses continue while stats stop, investigate telemetry separately.

Prepare a support request that can be investigated

Keep a short log excerpt around the failure rather than sharing an entire device dump. Include model, installed firmware, transport, pool host, assigned difficulty, time window and steps already tried. Remove private network details and personal identifiers that are unnecessary. Contact support yourself with that evidence; this page does not upload your logs.

  • Never include seed phrases, private keys or device administration passwords.
  • Keep both the error and the surrounding job context.
  • Save working pool settings before a controlled trial on another endpoint.

When is switching pools a useful experiment?

A controlled switch can help distinguish connection-specific behavior if hardware and network conditions remain comparable. It cannot settle every firmware issue or rank pools from a brief sample. If the error persists, retain both observations and return to the actual submission reason rather than chasing a higher best share.

Content updated: 3 October 2026 · Policy and sources checked: 6 September 2026

Questions about accepted and rejected shares

What rejection percentage is acceptable?

There is no single percentage that diagnoses every device and pool. The observation window, share difficulty, sample size and rejection reasons matter. Investigate a persistent change with logs and matching conditions. Avoid assuming that every rejected submission represents an equal amount of hashing time or an equally valuable block candidate.

Will lowering share difficulty improve my block odds?

Changing share difficulty changes the reporting threshold. It does not lower Bitcoin's network target. More frequent shares can improve feedback, but unnecessary submissions also create traffic. Use the difficulty behavior documented by the pool and firmware rather than optimizing the counter as though it were a measure of lottery entries.

How long should I wait for the first accepted share?

It depends on hashrate and assigned share difficulty, with random variation around the average. The waiting-time tool illustrates that relationship. First confirm connection, authorization and received jobs. A statistical wait cannot fix invalid credentials, a transport mismatch or a miner that is not hashing, so inspect those stages separately.

Can the wallet dashboard identify stale or duplicate shares?

The current SoloMining dashboard exposes counts and a rejection rate, not a complete rejection-reason breakdown. Use the device's response log to find a reason where available. If the response is missing or ambiguous, preserve its context and ask support; the percentage alone cannot reliably supply the missing classification.

Why did my best difficulty improve after a pool change?

A high-difficulty result can occur by chance. A later record does not establish that the new pool improved the probability of each effective hash. Compare accepted work and connection behavior separately. Neither accumulated shares nor a previous best result make the next independent hash closer to a valid block.