Mining Pool Latency and Stale Work Explained

Category: Mining and the Network · Published 2026-06-30

Technically reviewed and sourced on 2026-07-02

What does this mean?

Editorial review covers clarity and neutrality. Technical, security, and source reviews indicate whether an article's material claims were checked against relevant authoritative material. A source link being available does not by itself mean every claim has been verified. A reviewed status means the article's material claims were examined; it does not mean the article is exhaustive or that future protocol, market, or software changes cannot make it outdated.

What stratum latency actually is

Stratum is the protocol your miner uses to talk to a pool: the pool hands your miner a job (the block template to hash on), and your miner sends back shares (proofs it is working).¹ Latency is simply the round-trip time for those messages — how many milliseconds (ms) it takes a packet to travel from your miner to the pool and back.

The round-trip time to a nearby pool can be a few milliseconds; to a pool on another continent it can be a couple of hundred milliseconds, because the packets physically travel much farther. Actual numbers depend on distance and on how your ISP routes traffic, so they vary by connection. The real question is when those milliseconds cost you hashrate — and the answer is: in the brief window right after a new block appears on the network.

Stale work: the moments after a new block

Roughly every ten minutes, someone on the Bitcoin network finds a block. The instant that happens, the block you were trying to mine is already won — its template is now obsolete. The pool reacts by pushing a fresh job (often called a new job, or mining.notify) to every connected miner so you start hashing on the next block.

But that new job has to reach your miner. In the gap between the network finding a block and the new job landing on your machine, your miner keeps hashing on the old block. That work is stale — it can never produce a valid block, because the block it targets is already gone. It is hashrate spent on a lottery that is already over.

The size of that gap is mostly latency. Lower latency means the new job arrives sooner, so the stale window is shorter and less of your hashrate is wasted on a dead block.

How distance and routing size the stale window

A miner close to its pool gets each new job almost the moment the pool issues it; a miner far away waits a little longer for that same job, every time a block is found — and blocks are found on the order of 144 times a day. Geographic proximity tends to help, but routing quality matters too: a well-routed distant pool can beat a poorly-routed near one, so proximity does not always win.

Two measurements are easy to confuse. A quick TCP handshake time (a simple ping-like connect) is not the same as full stratum job-delivery performance, which is what actually governs stale work. And your miner-to-pool latency is different again from how fast a found block propagates through the pool’s Bitcoin node to the rest of the network.

Be honest about scale: for a small miner this is a fraction of a second, 144 times a day — a small slice of total hashing that trims waste without transforming odds. If you want current, comparable figures, measure them yourself; a dated latency test belongs on a ping test, with its method and date stated.

When you win: propagation and orphan risk

Latency cuts the other way too — in the rare moment a miner finds a block. When that happens, the pool software builds the full block and hands it to a validating Bitcoin node, which broadcasts it to the rest of the network. The faster that block propagates to other nodes, the better — note that this network-wide propagation is a different thing from your own miner-to-pool latency.

Why? If another miner finds a competing block at nearly the same instant and theirs spreads faster, yours can become an orphan — a valid block the rest of the network discards in favour of the chain everyone else built on.² An orphaned block pays you nothing. Orphan risk is highest at the moment of broadcast and fades after the first few confirmations.

A well-connected node, broadcasting quickly, lowers that risk. You do not manage this yourself — it is the pool's job — but it is a real reason that where and how a pool is hosted matters in the one moment that counts most: when you are the one who found the block.

The honest part: latency stops waste, it doesn't make luck

Here is the line we will not blur. In true-solo mining, you find a block when one of your hashes comes in below the network target — a threshold set by network difficulty, completely independent of which pool you use, how far away it is, or what share difficulty you mine at. Latency does not change that probability. Your odds depend on one thing: your hashrate.

What low latency does is make sure the hashrate you already pay for is spent on the right block instead of a dead one. It trims stale work; it does not manufacture luck. A small miner close to its pool has the same astronomical odds — on the order of many thousands of years on average for ~1 TH/s — as the same miner far from its pool; it just wastes a touch less effort getting there.

So treat low latency for what it is: a genuine, free efficiency gain, not a shortcut to a block. You keep more of your own hashrate working on live blocks — and the lottery stays exactly as fair, and as long, as it always was.

FAQ

Does mining closer to the pool improve my chance of finding a block?

No. In solo mining your odds depend only on your hashrate versus network difficulty — not on latency or which pool you choose. Low latency simply reduces stale work, so less of your hashrate is wasted on a block that has already been won.

What exactly is 'stale' work?

It is hashing your miner does on the previous block in the brief window after the network has already found one, before the pool's new job reaches you. That work can never produce a valid block, so it is effectively wasted — and lower latency shrinks that window.

How much hashrate does ~250 ms actually cost me?

Only a fraction of a second per block, around 144 times a day — a small slice of your total hashing. It is real waste worth removing for free by mining close, but it will not meaningfully change how long you would expect to wait for a block.

If I find a block, can I still lose it to latency?

Rarely, yes — that is an orphan. If a competing block propagates faster than yours, the network may discard yours and it pays nothing. Good propagation from a well-connected pool node lowers this risk, which fades after the first few confirmations.

How much does being close to a pool actually help?

Being close to your pool is a real, free efficiency gain that trims wasted (stale) work, but it does not change the underlying odds. How much it helps depends on distance and routing, and it should be measured, not assumed — a quick ping is not the same as full stratum performance.

Key takeaways

Stratum latency is round-trip time for job/share messages; it only costs hashrate in the brief window after a new block.
Stale work is hashing on an already-won block before the new job arrives; lower latency shrinks that window.
A quick TCP/ping test is not the same as full Stratum job-delivery performance or network block propagation.
Latency does not change the per-hash probability of finding a block — only your hashrate does.
Stale-work and orphan risk also depend on routing, firmware, and the pool's node connectivity; benchmarks must be dated and measured.

Sources

Stratum mining protocol (V1): shares meet a pool-assigned target — Bitcoin Wiki
Bitcoin Optech topics — Bitcoin Optech