What difficulty is, in units of work
Proof of work asks miners to find a block header whose SHA-256 double hash, read as a 256-bit number, falls below a target. Because the hash output is uniform, the chance any single attempt succeeds is target ÷ 2256, and the expected number of attempts is the reciprocal.
Difficulty is that reciprocal expressed relative to the easiest allowed target. Difficulty 1 corresponds to a target of 0xffff × 2208, which needs about 4.295 billion hashes per block. So at difficulty D a block needs about D × 232 hashes, and difficulty is best read as “how many multiples of 4.295 billion hashes a block costs”.
Everything else follows arithmetically. Divide the hashes per block by your hash rate and you get your expected seconds per block. Divide it by the protocol's target interval instead — 600 seconds for Bitcoin — and you get the hashrate the whole network must be running to produce blocks at that pace, which is the only way anyone knows the network hashrate. Nobody measures it; it is inferred from the difficulty the network has settled at.
Difficulty retargets every 2,016 blocks, or roughly two weeks. The protocol compares how long those 2,016 blocks actually took against the 20,160 minutes they should have taken and scales difficulty by the ratio, clamped to a factor of four in either direction. Sustained hashrate growth therefore produces sustained difficulty growth, and an estimate made at today's difficulty is optimistic for any period longer than a fortnight.
Why the wait is exponential, and why the median matters
Each hash attempt is an independent Bernoulli trial with a tiny success probability, and the trials arrive at a constant rate. That makes block discovery a Poisson process, and the waiting time between successes an exponential distribution. Two consequences follow, and both are routinely misread.
The process is memoryless. Having hashed for six months without finding a block does not improve the odds for tomorrow by any amount. There is no accumulated progress, no partial credit, and no sense in which you are “due”. The distribution of your remaining wait is identical to the distribution you faced on day one. Pool share counting can obscure this, but the underlying process has no memory at all.
The median is shorter than the mean. For an exponential distribution the median is ln 2 × the mean, about 69.3% of it. So if the expected wait is 100 days, half of all miners in that position find a block within 69.3 days — and the mean is pulled up by a long tail in which some wait several hundred. The probability of exceeding the mean is e−1 = 36.8%, and of exceeding twice the mean is e−2 = 13.5%. Quoting only the mean overstates the typical experience and understates the worst case.
The probability formula. P(at least one block within t) = 1 − e−t/E. It approaches 100% asymptotically and never reaches it: at ten times the mean you are at 99.995%, and there is no window that guarantees a block. The expected number of blocks in the window, t/E, is a different quantity and is larger than the probability whenever a second block in the same window is possible.
The constant. The literature and every mining calculator use D × 232. The exact figure implied by the maximum target is D × 248/0xffff = D × 4,295,032,833, which is 0.0015% larger. That difference is invisible next to the variance in a measured hashrate, so this calculator uses the conventional constant and records the exact one for completeness.
Worked example: 100 TH/s at difficulty 10¹⁴
Take a single modern ASIC running a sustained 100 TH/s — that is 1014 hashes per second — against a network difficulty of 1014.
- Hashes per block. 1014 × 4,294,967,296 = 4.294967×1023.
- Implied network hashrate. 4.294967×1023 ÷ 600 = 7.1583×1020 H/s, which is 715.83 EH/s.
- Your share. 1014 ÷ 7.1583×1020 = 1.397×10−7, or 0.00001397% — about one part in seven million.
- Expected seconds to a block. 4.294967×1023 ÷ 1014 = 4.294967×109 s.
- In years. 4.294967×109 ÷ 31,556,952 = 136.10 years.
- Median. 0.6931 × 136.10 = 94.35 years. Half of all miners in this position would find a block sooner than that.
- Chance in 24 hours. 1 − e−86,400 ÷ 4.294967×109 = 1 − e−0.0000201 = 0.00201%, or about one chance in 49,710.
- Expected coins per day. 86,400 ÷ 4.294967×109 = 2.0117×10−5 blocks, times 3.125 BTC = 6.287×10−5 BTC.
Step 8 is the number that matters, and it is also the number a mining pool pays you. A pool with 5% of the network finds a block roughly every 200 minutes and distributes it in proportion to contributed work, so your daily total is the same 6.287×10−5 BTC minus the pool fee. What changes is the variance, not the expectation: solo mining offers the same average with a 136-year mean wait and an all-or-nothing outcome. Convert that daily figure into money, and subtract electricity, with the crypto mining profitability calculator.
Reading the odds honestly
Read the median alongside the mean. If the expected wait is longer than the useful life of the hardware, solo mining is a lottery ticket rather than a business, and stating it that way is more honest than quoting an average nobody experiences. Conversely, if the median wait is a few days, solo mining is viable and the variance is tolerable.
Treat today's difficulty as a floor. Every figure here assumes difficulty stays where it is. It retargets every 2,016 blocks, and in a period of hashrate growth each retarget lengthens your expected wait. Any projection beyond a fortnight should either model a growth rate explicitly or be labelled as a best case.
Do not confuse the probability with the expected count. Over a window equal to the mean, the expected number of blocks is 1.0 and the probability of at least one is 63.2%. The gap is the chance of finding two or more. The two figures converge only when both are small, which is exactly the regime a small solo miner is in — and diverge when you are modelling a pool.
Sanity-check the share figure. Your percentage of the network should match what a pool dashboard shows if you are pointed at one. A wildly wrong figure almost always means a units mistake: difficulty entered in trillions when the field expects the plain number, or TH/s entered where H/s was wanted. The calculator flags shares above 50% for this reason, because a genuine majority is far less likely than a typo.
Remember what is not modelled. Transaction fees add to the block reward and vary enormously with mempool congestion. Stale and orphaned blocks lose you work that was genuinely done. Pool fees, whether a flat percentage or a pay-per-share arrangement, come off the top. And hardware does not sustain its rated hashrate through thermal throttling and firmware variation. For the full economic picture, take the expected coins per day from here and put it through the mining hardware ROI break-even calculator.
Expected time to find a block at difficulty 10¹⁴
| Your hashrate | Share of network | Expected time | Median time |
|---|---|---|---|
| 100 TH/s | 0.0000140% | 136.10 years | 94.35 years |
| 1 PH/s | 0.000140% | 13.61 years | 9.435 years |
| 10 PH/s | 0.00140% | 497.1 days | 344.6 days |
| 100 PH/s | 0.0140% | 49.71 days | 34.46 days |
| 1 EH/s | 0.140% | 4.971 days | 3.446 days |
| 10 EH/s | 1.397% | 11.93 hours | 8.27 hours |
| 100 EH/s | 13.97% | 71.58 minutes | 49.62 minutes |
Every row is the one above divided by ten, because expected time is inversely proportional to hashrate. That linearity is what makes pooling work: ten miners at 100 PH/s each experience the pool's 4.97-day wait rather than their own 49.7-day one, for the same expected income.
Probability of at least one block, as a multiple of the mean wait
| Elapsed ÷ mean | Probability of ≥ 1 block | Probability of none |
|---|---|---|
| 0.1 | 9.516% | 90.484% |
| 0.5 | 39.347% | 60.653% |
| 0.693 (median) | 50.000% | 50.000% |
| 1.0 | 63.212% | 36.788% |
| 2.0 | 86.466% | 13.534% |
| 3.0 | 95.021% | 4.979% |
| 5.0 | 99.326% | 0.674% |
| 10.0 | 99.995% | 0.005% |
Mining for the full expected time leaves a 36.8% chance of nothing at all, and mining for twice as long still leaves 13.5%. There is no elapsed time that guarantees a block, which is the practical meaning of an exponential wait.
Pooling changes the variance, not the expectation
A pool combines many miners' hashrate so that the group finds blocks frequently, then distributes the reward in proportion to work contributed. Your expected income is unchanged, minus the pool fee. What changes is the shape of the distribution: instead of a single enormous payout at an unpredictable time, you receive small regular ones.
That distinction matters because electricity bills arrive monthly and block discoveries do not. A miner whose median wait is measured in years cannot fund operations from block rewards, however sound the expected value. Pooling converts a lottery into an income stream at the cost of a percentage.
What pooling does not do is improve your odds. Anyone offering better-than-expected returns is either taking on variance risk themselves — which is what a pay-per-share pool does, and it charges for it — or is not solvent. The arithmetic on this page is the ceiling.
What this calculation leaves out
- Difficulty changes. Every figure assumes today's difficulty holds. Bitcoin retargets every 2,016 blocks, so a projection over months is optimistic whenever network hashrate is growing.
- Transaction fees. The block reward here is the subsidy only. Fees can be a small fraction of it in quiet periods and a substantial addition during congestion.
- Stale and orphaned blocks. Work on a block that loses a race is lost entirely. Propagation delay makes this more likely for miners poorly connected to the network.
- Pool fees and payout schemes. Proportional, pay-per-share and full-pay-per-share arrangements distribute variance differently between you and the pool, and charge accordingly.
- Real versus rated hashrate. Thermal throttling, firmware, power limits and hardware errors mean sustained hashrate is normally below the nameplate figure. Use what your dashboard reports.
- Downtime. Expected time assumes continuous hashing. Any outage extends the wait in direct proportion.
- The exact difficulty constant. D × 2³² is the convention; the exact value is 0.0015% larger. It has no practical effect but is worth knowing if you are reconciling against protocol source.
- Electricity, hardware and cooling. This calculator produces coins, not profit. Profit needs the cost side as well.
Key terms
- Difficulty
- A dimensionless number expressing how much harder the current target is than the easiest allowed one. At difficulty D a block needs about D × 2³² hashes.
- Target
- The 256-bit threshold a block header hash must fall below. Difficulty and target are reciprocals scaled by the maximum target, 0xffff·2²⁰⁸.
- Retarget
- Bitcoin's difficulty adjustment, applied every 2,016 blocks, which scales difficulty by the ratio of expected to actual elapsed time, clamped to a factor of four in either direction.
- Memoryless
- The property of an exponential waiting time that the remaining wait has the same distribution however long you have already waited. There is no accumulated progress toward a block.
- Stale block
- A validly mined block that loses a race to another block at the same height and earns nothing. Propagation speed and pool connectivity determine how often it happens.
Where this sits among mining calculations
This calculator answers one question — how long until a block — and that question sits upstream of every other mining number. Expected coins per day feeds directly into revenue; revenue minus electricity gives margin; margin against hardware cost gives a payback period. Work through those with the mining profitability calculator and the hardware ROI break-even calculator, both of which take a hashrate and a difficulty as their starting point.
It is also a useful lens on what proof of work actually is. The network is running roughly D × 232 ÷ 600 hashes every second purely to make history expensive to rewrite, and the cost of that computation is the security budget. The same arithmetic that gives a solo miner their odds gives an attacker the cost of a reorganisation, which is why the share-of-network figure is the one security analyses concentrate on.
The underlying mathematics is shared with two neighbouring calculations. Exhaustive key search has the identical structure — a fixed probability per trial and an exponential waiting time — and the key brute-force time calculator uses the same expected-attempts reasoning. And the birthday bound in the hash collision probability calculator shows the other way a hash function's output space can be searched, which costs the square root rather than the full space. Mining is a preimage-style search, so no such shortcut applies.
Proof of stake, used by several major chains, has no difficulty and no hashing, so none of this arithmetic transfers to it. Where you need a fee estimate for such a chain rather than a mining estimate, the Ethereum gas fee calculator models the relevant cost.