Block Finding

Watch the chance that the pool would have found at least one block by now. At the expected time-to-find (TTF), about 63 out of 100 comparable mining rounds would already have found at least one. That does not mean the next hash is due.

lottery intuition difficulty vs hashrate chance curves memoryless waits

Expected TTF 10m Elapsed 10m

The lottery version

Every hash is a discrete win-or-lose trial. Most tickets lose. A winning ticket is one whose hash lands below the network target.

More pool hashrate means more tickets per second. It does not make any single ticket luckier; it just gives the pool more independent tries.

Memoryless does not mean hopeless

Mining iterates through concrete headers, but the available header space is effectively refreshed by extranonce, timestamp, merkle root, version rolling, and new jobs.

Past misses do not make the next hash meaningfully more likely to win. The exact process is many Bernoulli trials, and at mining scale that behaves like the smooth curve shown here.

Reading the curves

CDF

CDF means cumulative distribution function. Here it is the chance the pool has found at least one block by a chosen time.

PDF

PDF means probability density function. It shows where wait times are most concentrated, not the chance of winning at one exact instant.

Why it matters

Miners usually want the CDF question: how likely are we to have found a block by now? The PDF explains the shape behind that curve.

Difficulty vs hashrate

Difficulty

Difficulty is how hard one valid block ticket is. Higher difficulty means fewer hashes land under the target, so each ticket is less likely to win.

Pool hashrate

Hashrate is how many tickets the pool buys per second. More hashrate does not change the ticket odds; it increases how quickly independent tries arrive.

Expected TTF

Expected time-to-find is the balance between those two forces: harder network work pushes it out, more pool hashrate pulls it in.

Nonce space vs block chance

XELIS work is deterministic

For a fixed XELIS job, the miner hashes concrete work: header work hash, timestamp, pool public key, the session extra nonce, and a miner nonce. The same inputs always produce the same hash.

Changing the nonce makes a new ticket

Incrementing the miner nonce does not make the next try luckier. It creates another deterministic candidate hash, which either lands below the target or it does not.

TTF comes from rate, not "used up" nonces

The pool model counts unique effective attempts per second against the current block work. XELIS also has session extra nonce space and fresh jobs, so the practical search domain is far larger than one small nonce counter.

So the hash check is deterministic, while block finding is modeled statistically because the pool is making many independent-looking deterministic attempts against a very small target.

Common questions

What is the probability we find a block within some time?

Use the curve as chance-by-that-time. If elapsed time equals the expected TTF, about 63 out of 100 comparable rounds would have found at least one block. At 0.693x expected TTF, about half would have found one. At 2.303x, about 90 would.

What is variance?

Variance is the size of the luck swings around the average. The average can be 10 minutes, but real waits still arrive unevenly: sometimes fast, sometimes much longer.

Why do low-hashrate pools feel choppier?

Lower hashrate buys fewer tickets per second, which increases the mean wait and the absolute wait-time variance. The relative curve has the same exponential shape, but over human time windows there are fewer wins to average together.

How does variance affect block finding time?

It means expected TTF is a long-run average, not a schedule. A pool can miss the expected time and still be behaving normally; the tail probabilities show when a wait is typical, long, or rare.

Difficulty and TTF Show the relationship

Think of block work as the expected number of hashes needed for one block at the current difficulty. Divide that work by pool hashrate to get expected time-to-find.

t_{expected} = \frac{W_{block}}{H_{pool}}

Doubling pool hashrate roughly halves expected TTF. Doubling block work roughly doubles expected TTF.

The model Show formulas

The page uses a Poisson block-arrival model, which gives an exponential wait time. More exactly, each hash is a Bernoulli trial: a deterministic candidate either lands below target or it does not. With tiny per-hash odds and many attempts, the discrete model is closely approximated by the smooth curve shown here.

exact discrete chance: $P (at least one) = 1 - {(1 - p)}^{n}$
rate: $λ = \frac{H_{pool}}{W_{block}}$
Poisson CDF approximation: $P (T \leq t) = 1 - e^{- λ t}$
PDF: $f (t) = λ e^{- λ t}$

In plain terms: the exact math counts the chance that none of the discrete tickets win. Because mining has extremely small ticket odds and extremely many tickets, that exact curve is visually the same as the Poisson/exponential model for practical pool TTF.

Why 1x expected TTF is 63.2% Show the derivation

Expected TTF is the mean wait, not the halfway point. In the mining-scale approximation, the mean wait is one over the block-finding rate.

E [T] = t_{expected} = \frac{1}{λ}

Put that mean wait back into the CDF. The rate cancels out, so every exponential wait has the same chance at exactly 1x expected TTF.

λ \times t_{expected} = λ \times \frac{1}{λ} = 1

P (T \leq t_{expected}) = 1 - e^{- 1} = 63.2 %

So a 10 minute expected TTF means: across many equivalent rounds, about 63 out of 100 would find at least one block by 10 minutes. The next hash is not due; the process is still memoryless.

The 50% point is the median wait. It arrives earlier, at 0.693x the expected TTF.

t_{50} = \frac{\ln (2)}{λ} \approx 0.693 \times t_{expected}

Useful probability points

50% 0.693x expected TTF

median: half of equivalent rounds found at least one block

63.2% 1.000x expected TTF

mean: the expected TTF point

90% 2.303x expected TTF

long wait, still normal

99% 4.605x expected TTF

rare tail, still possible