Pool Luck Explained: 3-Day, 7-Day and 30-Day Windows

Pool luck is a ratio: blocks the pool actually found divided by the blocks its hashrate said it should have found, measured over a stated window. The window is the whole argument. A pool holding 1% of network hashrate expects 1.44 blocks a day at 144 blocks daily, so one lucky block swings a 3-day ratio by about 23% but a 30-day ratio by only about 2%. For a miner with 1000 TH/s, the underlying value being measured is 0.00047353 BTC a day — about $40.39 at $85,294 per BTC.

A hand holding a smartphone showing an abstract green bar chart in flat diffuse light, tightly framed
Pool luck is a bar that fills unevenly, and the width of the window decides how uneven. Image: editorial.

Key takeaways

  • A 3-day window at 1% of network hashrate contains about 4.32 expected blocks, so a single extra block reads as roughly 23% above expectation.
  • A 30-day window at the same size contains about 43.2 expected blocks, which is why monthly luck numbers cluster near 100% and daily ones do not.
  • Under PPS+ the block-reward component is paid per accepted share hourly, so Pool Luck does not move it — only the transaction-fee component, distributed with PPLNS logic, carries any block-timing risk.
  • 1000 TH/s earns about 0.00001973 BTC an hour, near $1.68, which is the resolution at which a luck swing becomes visible in a statement.

What the number measures

Expected blocks are easy to derive. Take the pool's published hashrate, divide by the network hashrate that difficulty implies — 950.3 EH/s at a difficulty of 132.76 T — and multiply by 144, the number of blocks the Bitcoin network produces in a day. A pool with 1% of the network therefore expects 1.44 blocks a day, 4.32 in three days, 10.08 in seven days and 43.2 in thirty days.

Pool Luck is then simply found ÷ expected. Read it as a description of the recent past, not as a state of the world. A pool at 118% over seven days has not become 18% better at finding blocks; it has drawn a favourable sample from the same distribution every pool draws from. The next seven days are independent of the last seven, which is precisely why the window matters more than the headline.

There is a second quantity hidden in the same page: the pool's share of network hashrate. That ratio decides how many blocks are expected in the first place, so a luck reading taken while the pool is gaining hashrate is comparing an average over the window against a moving target. Nowhere is this more obvious than at difficulty changes, where the estimate for the next adjustment — +1.90% at the time of writing — is already visible before the retarget lands.

Why longer windows are calmer

The arithmetic of the table below is the reason. When a window contains only a handful of expected blocks, each realised block is a large fraction of the total, and the ratio jumps. When a window contains dozens of blocks, the same single block barely registers. Nothing about the pool changed between those two windows; the sample size did.

Expected blocks and sensitivity to a single block, illustrated for a pool holding 1% of network hashrate at difficulty 132.76 T.
WindowExpected blocksValue of one block in the ratioWhat the reading is good for
3 days4.32About 23%Spotting an outage or a redirect that stopped work
7 days10.08About 10%Comparing week to week without overreacting
30 days43.2About 2.3%Judging whether the underlying rate has changed

Practical rule: never act on the shortest window you can see. Use the 3-day figure to notice that something happened, the 7-day figure to decide whether it is still happening, and the 30-day figure to decide whether it matters. Most alerting mistakes in mining come from treating the first of those as the third.

Where luck actually reaches your balance

Under PPS+ the block-reward component is settled per accepted share at current difficulty and paid hourly, so a pool's block timing is the pool's problem, not yours. What remains exposed is the transaction-fee component, which is distributed with PPLNS logic: fees are collected when blocks are found, so their timing and their size both depend on chain activity. The listed fees are 4% on the PPS-settled block-reward part and 2% on the fee-distributed part, and they apply to different components rather than to one total.

Under PPLNS the exposure is direct. A distribution only exists once the pool finds a block, and it arrives after 6 confirmations, split by each miner's share of pool hashrate over the last 5 difficulty rounds. A dry spell is not a loss under that method, but it is a delay, and the delay grows with the length of the dry spell. The gap between the two listed rates is worth about $24.23 a month on the block-reward component alone at 1 PH/s, which is the price of handing block-timing risk to the pool rather than carrying it.

Worked example: one rig across three windows

Take 1000 TH/s — 1 PH/s — sitting in a PPS+ arrangement. The daily figure is 0.00047353 BTC, so an hour is 0.00047353 ÷ 24 = 0.00001973 BTC, roughly $1.68, and a 30-day month is 0.014206 BTC, about $1,211.68 gross. The same rig would need 21.1 days to accumulate 0.01 BTC at that rate, and its six-month line, drawn flat, runs from 0.014206 to 0.085235 BTC.

Now lay the windows over it. On the 3-day view the hourly credits should still arrive on schedule, because PPS+ does not care when blocks land; the only variable part is the thin fee slice. On the 7-day view a shortfall of 10% is within the noise of block timing alone. On the 30-day view, a persistent 10% shortfall is no longer luck — it is uptime, difficulty, or a worker that quietly stopped. Same rig, same dashboard, three different conclusions.

Line chart of cumulative BTC at 1000 TH/s over six months, stepping up in even monthly increments to 0.085235 BTC
Six months of cumulative BTC at 1000 TH/s with difficulty and pool luck held constant. Own calculation, 22 September 2026.

Reading luck next to hashrate

Luck on its own is not actionable, because it has no denominator. Put it beside a hashrate reading and the picture resolves: if ViaBTC Pool Hashrate is stable while the 3-day luck figure swings double digits, the pool is drawing a noisy sample. If the hashrate itself is falling, the swing has a curable cause, and the weekly pool statistics will show whether the movement is broad or concentrated in one operator.

That pairing is also the honest way to compare pools. A pool with a smaller hashrate will always appear to have more dramatic luck numbers, because small samples are dramatic. Compare the 30-day readings and the fee schedule, then decide; the short windows are for operations, not for selection.

Frequently asked questions

Does luck affect my income on PPS+?

Not the block-reward component, which is settled per accepted share at current difficulty and paid hourly. It can still touch the transaction-fee component, which is distributed with PPLNS logic and therefore depends on when blocks with fees are found.

Why is the 3-day pool luck number so extreme?

Because the sample is tiny. Three days at 1% of hashrate is about 4.32 expected blocks, so one extra block reads as roughly 23% and one missing block reads as roughly the same below. The number is accurate and useless for judging anything bigger than the window itself.

Should I switch pools because of a bad luck reading?

Only on the 30-day figure, and only after checking hashrate and uptime first. A pool at 95% over 30 days is a fact worth investigating; a pool at 78% over three days is arithmetic, not performance.

Use the long window to decide, the short one to act

Open the state page weekly and read the three luck windows as a set: 3-day for anomalies, 7-day for confirmation, 30-day for judgement. Multiply each against the hashrate that produced it before drawing a conclusion, and remember that your own payout at 1 PH/s is anchored near 0.00001973 BTC an hour regardless of which window is flashing. Decisions belong on the long window; the short one exists to tell you which day to go looking.

Data and sources: ViaBTC fee schedule[1], the earnings calculator and pool statistics[2][3]. Network difficulty 132.76 T, implied network hashrate 950.3 EH/s, the 3.125 BTC block subsidy, 144 blocks per day, a next-adjustment estimate of +1.90% and a BTC price of $85,294 were read from public chain data and market feeds, read 22 Sept 2026. Also read on the same date: LTC at $60.68 and KAS at $0.042829. All earnings figures are arithmetic on those inputs and change with difficulty, price and uptime.