The number that should have evened out by now

Your pool's luck stat reads 107%. You've been watching it for six months, refreshing the dashboard like it owes you something, waiting for the number to settle. Last quarter it sat at 94%. The quarter before that, 111%. Thousands of blocks in, and it still won't hold still.

Mining luck is governed by a memoryless probability process. Memoryless processes don't owe you convergence on any human timescale. That's the short answer. The long answer changes how you read every pool statistic you've ever trusted.

What "luck" actually measures, and why 100% is a fiction

Every block attempt in proof-of-work mining is an independent Bernoulli trial. The network sets a target difficulty, and each hash either clears it or doesn't. The probability of clearing it on any single hash is astronomically small: roughly one in 26 trillion for Bitcoin at typical difficulties. The expected number of hashes to find a block follows a geometric distribution.

Pool luck is simply the expected hashes to find N blocks divided by the actual hashes used. A pool that found 1,000 blocks using only 90% of the expected hash-work gets reported as running at 111% luck. Simple ratio.

The catch: variance in a geometric distribution doesn't collapse the way people intuitively expect. For a single block, the standard deviation of the hashes required equals the mean itself. That's a coefficient of variation of 100%. Observe N independent blocks, and the standard deviation of total hash-work scales with the square root of N. So for 100 blocks, you're at 10% standard deviation. For 10,000 blocks, you're at 1%.

Sounds like fast convergence. It is, mathematically. But "1% standard deviation" at Bitcoin's difficulty still represents an enormous absolute number of hashes, and pools with even substantial hash rates can take years to accumulate 10,000 blocks on their own.

Consider two miners, Priya and Tomás, who both join different pools on the same day with identical 10 PH/s rigs. Priya's pool runs 500 PH/s total and finds roughly one block every 50 minutes. Tomás's pool runs 50 PH/s and finds one block every eight hours or so. After one calendar year, Priya's pool has found around 10,500 blocks; Tomás's has found around 1,095. Theoretical luck standard deviation for Priya's pool: about 1%. For Tomás's: about 3%. Tomás's pool could spend an entire year running at 97% luck and that result sits comfortably within one standard deviation. He has no statistical reason to suspect anything is wrong. Priya, with ten times the sample, has tighter bounds, but she isn't immune either.

The memoryless property is the real villain

This is the part most guides skip entirely.

A geometric distribution is memoryless. That word has a precise meaning: the probability of finding the next block does not change based on how long you've been searching. If your pool has been hashing for twice the expected interval without a block, the probability of finding it on the very next hash is identical to what it was at the start. The process has no memory of your suffering. No debt accumulates. No correction is due.

This matters enormously for luck variance because it means outlier streaks don't self-correct. They simply end, eventually, replaced by new streaks that are also random. A pool running at 85% luck for 500 blocks isn't building up statistical pressure toward a lucky correction. It just keeps rolling dice. The next 500 blocks could easily be another unlucky stretch, or a lucky one. The two periods are completely independent.

Think of it like limescale in a kettle: the mineral deposits don't know they're supposed to dissolve. They just sit there until you actively remove them. Luck variance doesn't dissolve on its own either. It averages out only when you accumulate enough independent samples, and "enough" is a much bigger number than most pool dashboards imply.

Why pool size doesn't fix the problem, it just changes the timescale

Larger pools find blocks faster, so they accumulate samples faster. Real advantage. A pool with 30% of Bitcoin's total hash rate finds roughly 45,000 blocks per year at current network rates, and at that scale, the luck standard deviation drops below 0.5% annually. The stat genuinely stabilizes.

But most pools aren't capturing 30% of hash rate. A pool with 1% of network hash rate finds roughly 1,500 blocks per year. Standard deviation: about 2.6%. Over a two-year window, the pool would need to run at 98.2% or below, or 101.8% or above, before you could even claim the result was unusual at one standard deviation. That is a lot of room to look lucky or unlucky without anything anomalous actually happening.

Small pools face the starkest version of this. A pool capturing 0.1% of hash rate finds maybe 150 blocks per year. Standard deviation: over 8%. An 8% swing in either direction is completely routine. Calling a small pool lucky or unlucky based on a year of data is, statistically speaking, almost meaningless. And frankly, any journalist or forum poster who does it confidently doesn't understand the denominator.

What people consistently get wrong

The most persistent misconception is that luck variance is a short-term phenomenon that washes out over "long enough" periods, where "long enough" is assumed to be weeks or a few months. It isn't. Convergence to the mean is asymptotic, approaching 100% as sample size grows but doing so at the pace of the square root of N. Doubling your sample cuts the expected deviation by only about 29%.

The second misconception is that a pool running above 100% luck is somehow cheating the system or benefiting at another pool's expense. It isn't. Total blocks found across all pools always matches expected difficulty. One pool's lucky streak doesn't steal blocks from another. The luck stat is purely a within-pool measurement of variance.

The third misconception is the most financially consequential: using a pool's recent luck figure as a selection criterion. A pool showing 115% luck over the last 1,000 blocks has essentially no predictive power over the next 1,000. The memoryless property makes historical luck a description of the past, not a forecast. So if you're shopping pools based on recent luck numbers, you're doing something that feels rational and isn't.

Found your pool sitting at 94% luck over the last three months? If you're at a mid-sized pool with a few hundred blocks in that window, you're looking at noise. Completely normal noise, just wearing an unfortunate number.

The only thing luck variance genuinely tells you, over a large enough sample at a large enough pool, is whether the pool's software is functioning correctly and whether the difficulty accounting is honest. Everything else is the geometric distribution doing what it has always done: refusing, with complete mathematical indifference, to apologize for being random.