Bitcoin Mining Probability

Estimate the probability of finding a Bitcoin block from hashrate, network difficulty, and time, with a live simulated mining visualization.

Loading interactive simulation...

Lesson

The theory — Bitcoin Mining Probability

Proof of work is a lottery you cannot study for. To add a block you must present a header whose SHA-256 hash falls below a target, and since the hash of a changed header is unpredictable, the only method is to guess. Everything that follows is one consequence of that: expected guesses times how long a guess takes.

What each symbol means

D: difficulty — how small the target is, and therefore how many guesses a block costs. On this page it is a slider; on the real network it is not.
H: hashrate, guesses per second. It sets how fast you work through the search, and nothing else.
E[T]: D · 2³² / H, the expected wait. A mean, not a forecast — the first insight block below is about the difference.
p: the chance of a block in the next second. Not 1/E[T]: see step 4.

Where the formula comes from

Count the guesses a block costs, not the seconds. That is D · 2³², and it does not mention who is guessing — a phone and a data centre need the same number of attempts.
Divide by your guess rate. At the defaults, 160 × 10⁵ · 2³² / (800 × 10¹²) comes to about 86 seconds, which the readout rounds to 1.4m.
Now move the hashrate slider and watch Expected Time move in exact inverse proportion. Double H, halve the wait. On this page that is the whole story, and it is the part that is not true of Bitcoin.
Read the per-second chance carefully. It shows 1.157%, and 1/86 is 1.164% — close, but that is not the calculation being done. What is computed is 1 − e^(−1/E[T]), because a second holds many independent attempts and their chances compound rather than add.

How to read what you see

The sliders say that hashrate buys blocks. Drag Hashrate from 800 to 1600 and the expected wait halves, exactly. That is a true statement about this page and a false one about Bitcoin, and the gap between the two is the most important thing on the screen. The table further down runs the same formula at real difficulty, where a laptop needs 1.7 billion years and the whole network needs ten minutes — but look at its last column instead, where 1.7 billion years and ten minutes cost 678 TWh and 3.3 GWh. The waits differ by a factor of 10¹⁴ and the electricity does not, because the hashrate cancels: energy per block is D · 2³² multiplied by the joules a single hash costs, and nothing else.

Assumes: That every guess is independent and equally likely to win, which proof of work is designed to make true; that difficulty holds still while you wait, which it does here and does not on the network; and that a miner who solves a block keeps it. The last is not free — a block that reaches the network late can be orphaned, so a real miner’s income is slightly below what this formula promises. The simulation also scales difficulty and hashrate down by about a millionfold, as its own disclaimer says, so that blocks arrive while you are watching.
Breaks when: Difficulty is a slider here and a feedback controller in reality. Every 2016 blocks the network measures how long they actually took and moves D to bring the average back to ten minutes. So the relationship this page demonstrates runs the other way round on Bitcoin itself: adding hashrate does not produce blocks faster, it produces a higher difficulty within a fortnight, and the ten minutes returns. Since the reward per block is set by the protocol, more hashrate cannot mint more bitcoin — it can only divide the same issuance among more machines, and burn more electricity doing it. That is why the energy figure is not derivable from any of the mathematics on this page. The protocol fixes the ten minutes and fixes the reward. It fixes nothing whatsoever about the 3.3 GWh, which is set by what a block is worth and how efficient this year’s hardware is.

The expected time is not the typical time 🖖

At the default sliders the readout says about 86 seconds, but that is a mean, not a forecast. Each hash is an independent trial, so the wait is exponentially distributed, and an exponential's median is only ln 2 × its mean — about 60 seconds here. Roughly 63% of blocks therefore arrive sooner than "expected", while the average is propped up by a thin tail: 37% run longer than the mean and 5% take more than three times it. Start the simulation and read the event log, which prints each block's actual time beside the expected one — the short waits dominate the count and a few long ones do all the damage to the average.

Mining is a lottery, not a race 🖖

Every hash attempt is a lottery ticket with astronomically bad odds — the winning number is any hash below the target. You cannot 'work toward' a block; you simply buy more tickets per second by adding hashrate. Your chance of finding the next block is roughly your share of the total network hashrate, so a miner with 1% of the power wins about 1% of blocks over the long run.

The 32-bit nonce runs out in microseconds 🖖

A Bitcoin block header has only a 32-bit nonce — about 4.29 billion (2³²) values. A modern ASIC doing 100 TH/s burns through that entire range in roughly 43 microseconds, far too few tickets to find a block that now needs around 10²³ hashes. So miners keep generating fresh headers by tweaking the coinbase transaction's extra-nonce and the timestamp, quietly expanding the search space the header alone cannot provide.

How big is big

What finding one real block would take

The sliders above are a scaled model, so “difficulty 160” tells you nothing about whether you are a phone or a planet. This table runs the same formula at real Bitcoin: difficulty 1.262 × 10¹⁴ and a network hashrate near 900 EH/s, where they sat in August 2026. The last column multiplies each machine’s wait by the power it draws while waiting.

Mining with	Hashrate	Expected wait for one block	Electricity for that one block
A laptop CPU	10 MH/s	1.7 billion years	678 TWh
A gaming GPU	500 MH/s	34 million years	96.4 TWh
One mining ASIC	200 TH/s	86 years	2.6 GWh
A mining pool	50 EH/s	3.0 hours	3.3 GWh
The entire Bitcoin network	900 EH/s	10.0 minutes	3.3 GWh

Three things worth noticing. The sliders cannot reach any of this — the tool’s hardest setting is about 1.26 million times easier than real Bitcoin — so the model is deliberately shrunk to keep block times watchable. The bottom row is not a measurement: difficulty retargets every 2016 blocks precisely to hold ten minutes, which is how you can tell this table is arithmetically sound rather than merely plausible. And the last column does not follow the middle one. The waits span a factor of 10¹⁴; the electricity does not, because the hashrate cancels out of it — one ASIC and the entire network spend within 25% of each other on a block. What is left is efficiency alone, which is why the laptop’s figure is 257,000 times the ASIC’s: exactly the ratio of their joules per terahash.

Problems solved in full

Block wait time for 800 TH/s against difficulty 160 5 steps
800 TH/s of hardware is grinding against difficulty 160, and the difficulty slider counts in units of 10⁵. Work out how long the network waits for a block, then the chance one lands in any single second — and then whether “expected time” is what a miner actually experiences.
1. Every unit of difficulty costs 2³² hashes on average, so difficulty 160 is 1.6×10⁷ units and 6.872×10¹⁶ hashes per block. No hardware appears in that number: it is a property of the target alone.
  
  $D = 160 \times 1 0^{5} = 1.6 \times 1 0^{7}, D \cdot 2^{32} = 6.872 \times 1 0^{16}$
2. Divide by what the hardware delivers each second. 85.9 seconds, which the panel rounds to 1.4 m.
  
  $E [T] = \frac{D \cdot 2 ^{32}}{H} = \frac{6.872 \times 1 0 ^{16}}{8 \times 1 0 ^{14}} = 85.9 s = 1.4 min$
3. Now the per-second chance, where the obvious answer is wrong. One second buys 8×10¹⁴ attempts, each valid with probability 1/(6.872×10¹⁶), so the expected number of solutions inside that second is 0.011642. That is a count, not a probability — nothing stops two of those hashes from both working.
  
  $p = \frac{1}{6.872 \times 1 0 ^{16}} = 1.455 \times 1 0^{- 17}, H p = 0.011642$
4. Ask instead for the chance that every one of the 8×10¹⁴ attempts fails. Raising (1 − p) to that power collapses to e^−1/85.9 because p is so tiny, and the panel prints the complement: 1.157%. The 0.007-point gap from step 3 is the second that yields two blocks, counted twice there and once here.
  
  $P_{1} = 1 - (1 - p)^{H} = 1 - e^{- 1/85.9} = 0.011574 = 1.157%$
5. The same exponential answers a different question. The chance of still waiting after t seconds is e^−t/85.9; set that to a half and the median wait drops out at 59.5 seconds, a full 26 seconds under the mean.
  
  $P (T > t) = e^{- t /85.9}, 85.9 ln 2 = 59.5 s$
Answer

The panel prints an expected time of 1.4 m and a 1.157% chance each second, and one exponential produced both. The mean is not the typical wait: 63.2% of blocks arrive before the “expected” time and 4.98% take more than three times it, beyond 257 seconds. What makes mining feel unfair is the conditional version. A rig that has ground for 5 minutes without a block faces exactly the same 1.157% in the next second as one switched on a moment ago, because e^{−(s+t)/85.9} divided by e^−s/85.9 is e^−t/85.9 with no trace of s left in it. No miner is ever due. The streak counter on the panel climbs, and the odds it is counting against never noticed.

$P (T > s + t ∣ T > s) = e^{- t /85.9}, 1 - e^{- 1} = 63.2%, e^{- 3} = 4.98%$
Difficulty 850 against 300 TH/s split equally by 10 miners 5 steps
Difficulty 850 against 300 TH/s, and 10 miners splitting that hashrate equally. Find the network's block time, then what one of those miners sees in a day — which is not the same question.
1. Same equation, harder numbers: 8.5×10⁷ difficulty units at 2³² hashes each is 3.651×10¹⁷ hashes, and 3×10¹⁴ per second clears them in 1217 seconds. The panel rounds it to 20.3 m.
  
  $E [T] = \frac{8.5 \times 1 0 ^{7} \cdot 2 ^{32}}{3 \times 1 0 ^{14}} = 1217 s = 20.3 min$
2. The per-second chance shrinks with it, to 0.082%. Notice what is absent from both lines: the miner count. Ten rigs or 80, the chain's block rate is fixed by total hashrate and difficulty, so neither readout depends on how many of them there are.
  
  $P_{1} = 1 - e^{- 1/1217} = 8.215 \times 1 0^{- 4} = 0.082%$
3. It decides everything about one miner, though. Give each of the 10 an equal 30 TH/s and feed that into the same formula — 12,169 seconds, or 3.38 hours, between the blocks that are yours.
  
  $H_{1} = 30 \times 1 0^{12} : E_{1} = \frac{3.651 \times 1 0 ^{17}}{3 \times 1 0 ^{13}} = 12169 s = 3.38 h$
4. A day holds 86,400 seconds. That is 7.10 blocks for you and 71.0 for the 10 of you together.
  
  $μ_{1} = \frac{86400}{12169} = 7.10, μ_{10} = \frac{86400}{1217} = 71.0$
5. Blocks land independently at a fixed rate, so a day's count is Poisson and its standard deviation is the square root of its mean. Yours is √7.10 = 2.66 blocks of scatter on an expected 7.10.
  
  $σ = μ : \frac{7.10}{7.10} = 37.5%, \frac{71.0}{71.0} = 11.9%$
Answer

2.66 blocks of scatter on 7.10 is ±37.5%; the same day across all 10 miners is 71.0 blocks and only ±11.9%. Same chain, same hashrate, same equation — the entire difference is that σ/μ = 1/√μ, so taking a tenth of the flow multiplies your relative luck by √10 = 3.16. That is the arithmetic behind pooling: 10 miners who agree to share every block they collectively find trade a 37.5% swing in daily income for an 11.9% one, and not one extra hash gets computed. Neither readout above carries the miner count, and that is exactly right — expected time is a property of the chain, while the risk is a property of your slice of it.

$\frac{σ}{μ} = \frac{1}{μ} ⟹ μ \to \frac{μ}{10} \Rightarrow \times 10 = 3.16$

References (5)

The block-arrival statistics behind the mean-versus-median claim: R. Bowden, H. P. Keeler, A. E. Krzesinski and P. G. Taylor, "Modeling and analysis of block arrival times in the Bitcoin blockchain." Stochastic Models 36(4), 602–637, 2020.
Measured block propagation on the live network: C. Decker and R. Wattenhofer, "Information propagation in the Bitcoin network." IEEE P2P 2013 Proceedings, 1–10, 2013.
The ten-minute target and the retargeting that holds it — sections 4 and 11: S. Nakamoto, "Bitcoin: A Peer-to-Peer Electronic Cash System", 2008. Self-published; no DOI was ever assigned.
Why a pool exists at all, which is the jump between the last two rows of the ladder: M. Rosenfeld, "Analysis of Bitcoin Pooled Mining Reward Systems", 2011. arXiv:1112.4980.
Where the energy column’s 22 J/TH fleet efficiency is anchored: Cambridge Centre for Alternative Finance, Cambridge Bitcoin Electricity Consumption Index (CBECI) — the index put the network at roughly 170–180 TWh/yr in early 2026, and its 2023 methodology revision is itself worth reading on how such estimates go wrong.

By the 42Math team · Updated 2026-06-13

Reviewed against published sources. Corrections welcome. Editorial policy · Corrections

All Tidal Zone lessons →

Example problems

Easy - Low difficulty (20), 2000 TH/s → blocks arrive frequently — large target zone
Balanced - Balanced defaults: 800 TH/s, difficulty 160 → moderate block frequency
Hard - Hard mode: difficulty 850, 300 TH/s → tiny target, very rare blocks