How Mining Pool Hashrate Estimates Work

Your miner and your pool often report different hashrates. This explains why — one is a direct measurement, the other a statistical estimate from shares — and gives the properly-defined estimation relationship.

Category: Mining and the Network · Published 2026-07-01

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.

Two numbers, measured two different ways

Your miner reports one hashrate; your pool’s stats page reports another. This is normal and does not mean lost work. Your miner measures the work its own chips do, moment to moment. A pool cannot see your chips — it only sees the shares you submit (proofs that your miner met an assigned difficulty target)¹ and works backwards to estimate your hashrate. A measurement and a statistical estimate rarely match exactly, and the gap is widest in the first minutes after connecting, before many shares have arrived.

How a pool estimates hashrate from shares

Each accepted share proves your miner found a hash meeting its assigned share difficulty. Because one unit of difficulty corresponds to about 2³² hashes on average, a pool estimates hashrate roughly as:¹

estimated hashrate ≈ (sum of accepted share difficulties × 2³²) ÷ elapsed seconds

This is an estimate, not a direct reading.² Different pools use different time windows and smoothing, so two pools can report the same miner slightly differently. A share is more than “just a hash” — it is a hash that met a set target, which is what makes it usable as statistical evidence of work done.

Averaging windows and variance

Shares arrive as random events, so pools average them over several windows at once (for example 1m, 5m, 1h, 1d). Short windows are twitchy by design: a few extra or missing shares swing a 1-minute figure widely. Longer windows pool more shares, so random noise cancels out and the reading is steadier. To compare against your miner’s own screen, use a longer window. Convergence within any particular percentage is not guaranteed — even a one-day average can differ from your local reading.

Accepted vs. rejected shares

Only accepted shares feed the estimate. Rejected shares — for example stale ones submitted for a block that was already replaced, or malformed ones — do not count. A small reject rate is normal; a persistently high one can point to latency, overclocking instability, or a connection problem.

Estimates versus your odds

A low or jumpy pool reading does not mean lost hashrate or worse odds. Your chance of finding a block depends on the real hashes your hardware produces against the network target — not on the pool’s display number or the share difficulty it assigns. In solo mining, shares are used for statistics and difficulty tuning, not as monetary credits; in shared pooled mining, shares can map to payout. Either way, share difficulty affects how often you report in, not your probability of a block.

Reading small and new miners sensibly

A brand-new connection has submitted few shares, so every window reads low until data accumulates. A very small miner assigned a high difficulty submits shares so rarely that its estimate is starved of data and looks jumpy — while the hardware is hashing normally. Give a healthy miner time and compare longer windows; do not expect any fixed “within a few percent within a day” promise, because it is a statistical estimate, not a guarantee.

FAQ

Why does my pool hashrate differ from my miner's screen?

Your miner measures its chips directly; the pool estimates your hashrate statistically from the shares you submit. A measurement and an estimate rarely match exactly, especially soon after connecting.

What is the correct hashrate-estimate relationship?

Roughly, estimated hashrate ≈ (sum of accepted share difficulties × 2³²) ÷ elapsed seconds, because one unit of difficulty corresponds to about 2³² hashes on average. It is an estimate; pools differ in windows and smoothing.

Does a lower pool reading mean I lost hashrate or have worse odds?

No. Every accepted share is counted, and your odds depend on the real hashes your chips produce against the network target, not on the displayed estimate or your share difficulty.

Which window should I compare to my miner?

Use a longer window (such as 1h or 1d) rather than 1m. Longer windows pool more shares and are steadier, though even a day's average can still differ from your local reading.

Will the two numbers always agree within a few percent?

Not guaranteed. They often move closer over time as shares accumulate, but a share-based estimate can still differ from a direct measurement. Convergence within a specific percentage is not promised.

Key takeaways

Your miner measures hashrate directly; a pool estimates it statistically from submitted shares.
A common estimate is (sum of accepted share difficulties × 2³²) ÷ elapsed seconds — the 2³² factor is a difficulty-1 convention, not an exact identity.
Short windows fluctuate; longer windows are steadier, but convergence within any fixed percentage is not guaranteed.
A low or jumpy reading does not mean lost hashrate or worse odds; only shares meeting the assigned target are submitted.

Sources

Bitcoin developer documentation — Bitcoin Project
Difficulty (difficulty-1 work ≈ 2^32 hashes convention) — Bitcoin Wiki (secondary/optional reading)