Mining Pools & How Rewards Are Shared

The mining process is a brute-force search where each hash is an independent dice roll against the target. That memoryless, all-or-nothing nature creates a painful practical problem: even a substantial miner can go a very long time earning nothing before getting lucky. Mining pools exist to solve that variance problem — and in solving it, they create the single biggest centralization worry in Bitcoin. This page is the why, the how, and the careful boundary of what pools can actually do.

Why solo mining is a brutal lottery

Suppose you control a small slice of the total network hashrate — say one ten-thousandth. On average you’d expect to find roughly one block every ~70 days (one in 10,000 of the ~144 blocks per day). But “on average” hides ferocious variance: because each block is a Poisson event, you might find two in a week and then nothing for half a year. Your expected income is fine; your realized income is a wild, unpredictable ride that can’t pay an electricity bill that arrives every month.

   Solo miner with 0.01% of hashrate:
   month 1: ████ (1 block, jackpot)   month 2: ░ (nothing)   month 3: ░ (nothing)
   month 4: ░    month 5: ░    month 6: ░    month 7: ████   ...
   → same long-run average, but cash flow is terrifying

Most miners would happily trade a little expected value for a steady, predictable payout. That trade is exactly what a pool provides.

How a pool works: shares

A pool aggregates many miners’ hashrate into one giant searcher and then splits the rewards in proportion to work contributed. The clever part is measuring each miner’s contribution before anyone finds a real block. The tool is the share.

The pool operator hands out work and asks miners to find hashes below an easier, pool-set target — much higher (easier) than the real network target. A hash that beats this easy target is a share: proof the miner is genuinely grinding, even though the share itself isn’t a valid block.

   network target  : 0000000000a3...         (real block — astronomically rare)
   pool   target   : 0000a3...                (a "share" — common, found constantly)

   every share = statistical evidence of work done
   occasionally, a submitted hash also clears the REAL target → the pool wins a block

Because shares arrive steadily and are far more frequent than blocks, they give the pool a smooth, fair, real-time measurement of who contributed how much. When any member’s hash happens to clear the real network target, the pool collects the full block reward and distributes it to members according to their shares. The whole scheme is just the mining process run at two difficulty levels at once: a low one for accounting, the real one for actually winning.

PPS vs PPLNS, at a high level

Pools differ mainly in who absorbs the variance and how they pay shares:

Scheme	How you’re paid	Who bears the luck risk
PPS (Pay-Per-Share)	A fixed amount for every share, immediately, whether or not the pool finds a block	The pool operator (charges a higher fee for taking the risk)
PPLNS (Pay-Per-Last-N-Shares)	A slice of actual blocks the pool finds, based on your shares in the recent window	The miners (payouts swing with the pool’s luck)

• PPS is the smoothest possible income — the operator effectively pays you your statistical expectation up front and eats the variance themselves, funded by fees. If the pool has a dry spell, you still get paid.
• PPLNS ties you to the pool’s real results: great during lucky streaks, lean during unlucky ones, but typically lower fees and resistant to “pool hopping” (jumping between pools to skim the good periods). The recurring window discourages hopping because rewards depend on sustained contribution.

Real pools run many variants and hybrids, but the axis is always the same: how much variance does the miner keep, and what fee do they pay to shed it? This is a clean little study in game theory — aligning the operator’s and the miners’ incentives so both are better off cooperating.

Centralization: what pools can and cannot do

Pools concentrate decision-making, and that deserves a clear-eyed accounting. When a pool wins a block, it’s the pool operator who constructed the candidate block — chose which transactions to include and in what order.

A pool operator CAN:

• Censor or deprioritize transactions — refuse to include certain ones in blocks the pool mines.
• Choose ordering of transactions (relevant to MEV-style games).
• Direct hashrate toward a particular chain tip during a fork — i.e., influence which block history gets extended.

A pool operator CANNOT:

• Steal your coins. Mining never touches anyone’s keys; the operator can’t move funds it doesn’t have the signatures for. Bitcoin’s ownership rules are enforced by every full node independently.
• Forge transactions or inflate supply. A block with an invalid transaction or an oversized subsidy is rejected by every full node, so the pool would simply have wasted its work.
• Permanently rewrite history alone — that requires majority hashrate sustained over time, and even then is bounded by what the most-work chain rule allows.

The real risk is concentration, not theft

The nightmare scenario isn’t a pool stealing coins — the math forbids that. It’s a small number of pools commanding a large fraction of hashrate and colluding to censor transactions or to mount a 51%-style reorg (see selfish mining & 51%). The defense is partly social (miners can leave a misbehaving pool instantly, redirecting their hardware elsewhere) and partly technical: newer protocols like Stratum V2 let individual miners, not the pool operator, choose which transactions go into the blocks they help find — pushing the censorship-resistant property back down to the people who own the hardware.

Pools don’t change the security budget — only its distribution

A pool is just a way to share the same rewards more smoothly; it doesn’t create or destroy hashrate, and it doesn’t change how expensive an attack is. It changes who decides block contents and how income variance is allocated — important governance questions, but separate from the raw energy security that Proof of Work provides.

The thread

How does this help untrusting strangers agree on one ledger? Pools are a fascinating stress test of the model: they let mutually distrusting miners cooperate (via verifiable shares) and let users keep trusting the ledger even though block construction is concentrated. The reason it still works is the hard floor under everything — every full node independently validates every block, so no matter how centralized production becomes, the rules stay decentralized. A pool can pick what goes in a block, but it cannot make the network accept a block that breaks the rules. Influence over ordering is negotiable; influence over validity is not.

Check your understanding

1. Why is solo mining’s expected income fine but its realized income unacceptable for most miners?
2. What is a “share,” and how does it let a pool measure contribution before any real block is found?
3. Contrast PPS and PPLNS by who bears the variance and how each handles pool hopping.
4. List two things a pool operator can do and two things it cannot do. Why is the “cannot” list enforced?
5. Explain why mining pools concentrate block construction without concentrating rule enforcement, and how Stratum V2 pushes back on the former.