What Creates Stale Shares in Bitcoin Mining?

A share can be perfectly valid proof of work and still arrive too late to matter. That is what creates stale shares in Bitcoin mining. Your miner was working on a job that the pool had already replaced after the network moved to a new block tip.

For home miners, this distinction matters. A stale share does not mean your hardware is broken, your hashrate disappeared, or a pool took your work. It means the work was tied to an obsolete block template when the pool received it. In solo and lottery mining, stale work cannot help solve the current block. The only useful response is to identify where the delay occurred, measure it, and reduce the parts you control.

What Creates Stale Shares?

Bitcoin mining is a race against a moving target. A pool gives your miner a job built on the current chain tip. Your miner hashes that job and submits shares that meet the pool's assigned difficulty. When anyone finds a valid Bitcoin block, the network accepts a new tip. The old template is no longer the template miners should be extending.

The pool must learn about that block, validate it, build a new candidate template, and send a new job to connected miners. Your miner must receive the job, stop hashing the old one, and start hashing the replacement. Any share found during that transition can be stale.

The central cause is not simply latency in the abstract. It is elapsed time between the moment the network changes and the moment your miner begins working on the replacement job. A short delay is normal. Bitcoin is a distributed system. Some stale work is an expected cost of coordinating miners across the internet.

The question is whether your rate reflects ordinary network behavior or a problem in your connection, local network, miner, or pool job-distribution path.

A new block changes the job

Most stale shares occur immediately after a new block is found. This is sometimes called a block transition. Until your miner receives a clean job, it keeps searching an old candidate block.

A miner can also submit an old share after it has received the new job. The share may have been found milliseconds earlier but sat in a device queue, a local proxy, or a congested network buffer before transmission. The pool sees the submission after the old job is invalidated and rejects it as stale.

This is why a rejection log needs context. A stale rejection is different from an invalid share. Stale means the proof was associated with old work. Invalid usually means the submitted result did not meet the assigned target or was malformed. Treating every rejection as the same failure hides the actual cause.

Propagation delay reaches every layer

A new block has to travel from the Bitcoin network to the pool. The pool then has to distribute the replacement work to miners. Each step adds delay.

The path can include the pool's Bitcoin node, template construction, job broadcasting, your internet provider, Wi-Fi, a router, a Stratum proxy, and the miner itself. A slow link at any one point can add stale work. The slowest recurring point often matters more than average ping.

Suppose your miner normally sees 35 ms of latency, but Wi-Fi congestion creates a one-second burst when another device starts a large upload. Average latency may still look fine. During a block transition, that one second can keep the miner on stale work long enough to show up in the rejection rate.

For a small ESP32-class miner, local network conditions are often more relevant than distance on a map. Weak signal, crowded 2.4 GHz spectrum, power-saving behavior, or a busy access point can interrupt job delivery. A wired ASIC can have the same problem through a saturated router, overloaded proxy host, or unstable upstream connection.

Pool Work Distribution Also Matters

The pool controls part of the stale-share path. It decides how it learns about new blocks, how it builds jobs, and how it distributes those jobs to connected miners. Those are infrastructure behaviors, not matters of faith.

A pool connected to its own fully validating Bitcoin node can construct work from its own view of the chain. That does not repeal propagation delay. It makes the work source and the chain state operationally direct. The remaining question is how quickly a fresh job reaches your specific miner.

A pool's server location may matter, but it is not the whole story. Route quality can matter more than geographic distance. A miner with a stable 45 ms path to a server can perform better than one with a nominally closer server reached through an unreliable route. Test the endpoint you actually use, at the times you actually mine.

NexusPool provides fixed and geo-steered Bitcoin endpoints, along with latency tools and live fleet statistics. Those tools are useful only if you use them to compare observed behavior: connection latency, job updates, accepted shares, and stale rejections over enough time to rule out a single bad hour.

Stratum version is not a magic stale-share switch

Stratum V1 and Stratum V2 solve different operational problems in different ways. Native encrypted Stratum V2 can protect the connection and authenticate the pool through authority-key pinning. It can also provide a cleaner protocol model for supported miners. None of that means encryption alone removes stale shares.

Staleness remains tied to how fast the miner receives and applies new work. A V2-capable device may benefit from a direct V2 connection, but it still depends on its firmware, local network, route, and the pool's job-distribution behavior. A V1 miner can also maintain a low stale rate on a healthy connection.

For most miners, the practical advantage is avoiding unnecessary machinery. If a pool supports both protocols on one connection point, native V2 hardware can use V2 while V1 hardware continues without a translator. A translator is another process and another network hop to inspect when results look wrong.

The Local Causes Worth Checking First

Before blaming an endpoint, check the equipment under your control. The goal is not to eliminate every stale share. It is to find avoidable delay.

Start with the miner's clock, firmware logs, and connection uptime. A device that reconnects repeatedly may miss job notifications or submit buffered work after reconnecting. Review whether the stale rate rises around reconnects, router restarts, power events, or firmware crashes.

Then look at the local network. Put a test miner on Ethernet if practical. If it must use Wi-Fi, test signal quality where the miner sits, not next to the router. Disable aggressive client isolation or power-saving settings that interrupt persistent connections. Check whether another device is saturating upload bandwidth. Mining share traffic is small, but job notifications and submissions still suffer when buffers fill.

For ASICs using a local proxy, test a direct connection briefly if your pool and setup allow it. This is not always the permanent answer. A proxy can be useful for fleet management or compatibility. It is a diagnostic step that tells you whether the proxy host, its CPU, its network interface, or its configuration is delaying work.

Dynamic per-rig difficulty also affects how clearly you can observe the problem. Difficulty does not create stales by itself, but very infrequent shares give you less data. A home miner may need days or weeks before a stale percentage says much. Do not declare a connection healthy or broken from three rejected shares.

How to Measure Stale Shares Without Fooling Yourself

Use a rate, not a raw count:

stale share rate = stale shares / total submitted shares

Keep invalid shares separate. Also record disconnects and rejected-share messages separately from shares that were never submitted because the miner was offline. Those are all lost mining time or lost work in different forms, and they point to different fixes.

Measure across enough submissions to reduce noise. A high-hashrate ASIC may generate useful data quickly. A Bitaxe or NerdQaxe may need a longer sample. Compare similar time windows, preferably before and after one change. If you change the pool endpoint, move from Wi-Fi to Ethernet, update firmware, and reboot the router on the same day, you will not know which change helped.

Watch the timing of stale rejections. A small cluster around global block discoveries is expected. Stales appearing continuously, in bursts unrelated to block transitions, or alongside reconnects are more suspicious. They can indicate delayed submission, connection instability, incorrect proxy behavior, or firmware handling that deserves inspection.

The right target depends on your setup. No honest operator can promise zero stales across every miner and every route. What you can demand is visibility into accepted and rejected work, clear rejection reasons, and a path to verify the pool's accounting rather than a dashboard total that asks for belief.

Your miner cannot control when another miner finds a block. It can control how quickly it hears about the next job, and you can control whether the system gives you enough evidence to diagnose the gap. Trust nothing. Verify your rejected-share rate.