Solo odds methodology
The exact math behind the solo mining odds calculator, and why it can legitimately disagree with another site’s numbers for the identical hashrate.
The odds formula
Solo mining is a Bernoulli trial repeated once per block: your hashrate’s share of the network is your probability of finding any single block.
p = yourHashrate / networkHashrate // probability per block P(at least one block within n blocks) = 1 − (1 − p)^n // exact binomial complement
n is however many blocks fall in the window you care about — 6 for an hour, 144 for a day, 144×30.44 for a month, and so on. “Expected time to a block” is simply 1 / (p × 144) days — the inverse of your expected daily block rate.
This is deliberately the exact formula, not the common 1 − exp(−p×n) approximation — at solo-mining hashrates the two are indistinguishable to many significant digits, so exactness is chosen for having no error term to reason about, not because it changes the answer.
Reward if you win
rewardBtc = blockSubsidy(currentHeight) + avgTxFeesPerBlock
blockSubsidy follows the halving schedule exactly — see the halving countdown.
Why calculators disagree
Network hashrate isn’t measured directly anywhere — it’s inferred from how quickly recent blocks were found, since faster blocks imply more total computing power competing for them. Different sites infer it with different trailing windows or smoothing methods, so the same device hashrate legitimately produces different odds on different calculators even when every formula is correct. minermath uses mempool.space’s own 3-day trailing average (see below) — a competitor using a 1-day or 7-day window will show a different number from the identical underlying block data, and neither is wrong.
Data sources
| Figure | Source | Refresh |
|---|---|---|
| Current network hashrate | mempool.space /api/v1/mining/hashrate/3d (currentHashrate — mempool’s own 3-day trailing average) | 10 min |
| Historical difficulty (for verified wins’ “odds beaten”) | mempool.space /api/v1/mining/difficulty-adjustments/all, one row per ~2-week retarget | backfilled once, per-adjustment after |
A verified win’s “odds beaten” on the solo block wins dataset uses the difficulty that was actually in effect at that block height — never today’s difficulty — and is left blank rather than estimated when no historical epoch row covers that height yet. The same live snapshot backs the /api/v1/network and /api/v1/solo-block-wins endpoints.
Questions
Why do different solo mining calculators show different odds for the same hashrate?
Almost always because they use different network-hashrate estimates, not because the odds math itself differs — network hashrate is inferred from recent block times, not measured, so any two sites using a different trailing window will compute a different number. See "Why calculators disagree" below.
Is the exact binomial formula meaningfully different from the simpler exp() approximation other calculators use?
At solo-mining hashrates (probability per block around 1e-9 to 1e-6) the two agree to many significant digits — the exact form is used here because it has no error term to reason about, not because the approximation would visibly disagree at these odds.