Mining Luck & Variance
Understanding the probabilistic nature of block discovery
Mining as a Poisson Process
Bitcoin mining is fundamentally a Poisson process. Each hash has an independent, identically distributed (i.i.d.) probability of finding a valid block. This means:
- Block discovery follows an exponential distribution
- Past results don't affect future probabilities ("memoryless")
- Multiple block discoveries follow a Poisson distribution
- Variance is inherent and unavoidable
Why This Matters
Because mining is probabilistic, pools don't find blocks at a constant rate. A pool with 10% hashrate might find 8 blocks one day and 15 the next — both are statistically normal outcomes.
- $X$
- Number of blocks found
- $k$
- Specific number of blocks
- $\lambda$
- Expected blocks (mean of distribution)
- $e$
- Euler's number (≈ 2.718)
Luck Calculation
"Luck" quantifies how a pool's actual block discovery compares to statistical expectation:
Interpretation
| Luck % | Meaning | Example (Expected: 100 blocks) |
|---|---|---|
| 100% | Exactly as expected | Found exactly 100 blocks |
| 120% | 20% more than expected (lucky) | Found 120 blocks |
| 80% | 20% less than expected (unlucky) | Found 80 blocks |
Over long periods, luck converges toward 100%. Short-term deviations are normal and expected. The larger the pool (more expected blocks), the faster convergence occurs.
Expected Blocks
Expected blocks are calculated from the pool's hashrate share:
ELEKTRON's Approach
Since we can't directly measure pool hashrate, we estimate share from recent block history using a rolling window:
- $w$
- Rolling window (default: 30 days)
- $B_{pool,i}$
- Blocks found by pool on day $i$
- $B_{total,i}$
- Total blocks on day $i$
Using rolling share (instead of fixed share) accounts for pools growing or shrinking over time, giving a more accurate luck calculation.
Variance & Convergence
Poisson Variance
For a Poisson distribution, variance equals the mean:
This has important implications:
Standard Deviation of Luck
- $\lambda$
- Expected blocks in the period
Variance vs Pool Size
| Expected Blocks/Day | ~Pool Share | Luck Std Dev | 95% Range |
|---|---|---|---|
| 1 | 0.7% | ±100% | 0-300% |
| 4 | 2.8% | ±50% | 0-200% |
| 14 | 10% | ±27% | 46-154% |
| 43 | 30% | ±15% | 70-130% |
Small pools experience extreme luck swings. A 1% pool might find 0 blocks one day (0% luck) and 4 blocks the next (400% luck) — both within normal statistical bounds.
Rolling Luck Analysis
To smooth out daily noise, ELEKTRON calculates rolling luck over windows:
Window Selection
| Window | Use Case | Trade-off |
|---|---|---|
| 1 day | Real-time monitoring | High noise, immediate signal |
| 7 days | Weekly performance | Balanced noise/signal |
| 30 days | Monthly assessment | Low noise, lagged signal |
| 90 days | Long-term trend | Very smooth, misses short-term |
Coefficient of Variation
The coefficient of variation (CV) normalizes variance relative to the mean, allowing comparison across pools of different sizes:
- $\sigma$
- Standard deviation of daily luck
- $\mu$
- Mean luck (should be ~100% over time)
CV Interpretation
| CV Range | Interpretation |
|---|---|
| < 15% | Very stable (large pool) |
| 15-30% | Moderate variance |
| 30-50% | High variance (small pool) |
| > 50% | Extreme variance (very small pool) |
Dominance-Luck Correlation
ELEKTRON tracks the relationship between pool size (dominance) and luck variance. Larger pools have lower variance due to the law of large numbers. This creates "convergence thresholds" — hashrate shares where luck stabilizes within certain ranges.
A pool needs approximately 5-10% network share for daily luck to consistently stay within ±20% of expected. Smaller pools should evaluate luck over longer periods (weeks/months) to avoid noise-driven conclusions.