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.

It actually happened — GHash.io and the 51% scare of 2014

The centralization worry isn’t hypothetical. In 2014 the pool GHash.io grew so large that for a brief stretch in mid-2014 it commanded around half of the entire network’s hashrate — by some measurements briefly topping 51%. It never attacked anything, but the mere fact that one operator could have unilaterally reorged the chain or censored at will set off alarm across the ecosystem. The response was telling: under public pressure GHash.io voluntarily pledged to cap itself near 40% and urged participants to spread out, and miners — who can repoint their hardware at another pool in minutes — drifted away until the pool faded. It remains the cleanest demonstration of the point above: the defense against pool concentration is partly social, because hashrate is mobile and a pool that frightens the network can be abandoned overnight. See the 51% attack family.

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.

The architect’s lens

Pools aren’t a protocol rule — they’re an emergent layer on top of mining. The five questions still sharpen the picture:

• Why does it exist? To kill the brutal variance of solo mining. Each block is a memoryless Poisson event, so a 0.01%-hashrate miner expects ~1 block every ~70 days but might wait half a year — pools convert that lottery into a steady, bill-payable income.
• What problem does it solve? Measuring contribution before anyone finds a real block. The share — a hash beating an easier, pool-set target — is statistical proof of grinding, arriving constantly, letting rewards be split fairly in proportion to work.
• What are the trade-offs? Concentration of block construction: the operator chooses which transactions go in and in what order, enabling censorship, ordering games, and hashrate direction during forks (GHash.io briefly topped ~51% in 2014). The PPS vs PPLNS axis just moves variance between operator and miners for a fee.
• When is this the wrong design? When censorship-resistance at the construction layer matters more than smooth income — solo mining (or Stratum V2, which returns transaction selection to individual miners) trades steady payouts for keeping block-building decentralized.
• What breaks if you remove it? Nothing in consensus — every full node still validates independently, so a pool can never make the network accept a rule-breaking block or steal coins. You’d only lose income-smoothing, pushing small miners out and arguably worsening centralization, not curing it.

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.

Show answers

1. Each block is a memoryless Poisson event, so a small miner’s realized income is wildly variable — a jackpot one month, then nothing for half a year — even though the long-run expected income is fine. That variance can’t pay an electricity bill that arrives every month.
2. A share is a hash that beats an easier, pool-set target (much higher than the real network target) — proof the miner is genuinely grinding, even though the share isn’t a valid block. Shares arrive steadily and far more often than blocks, giving a smooth, fair, real-time measure of who contributed how much.
3. PPS (Pay-Per-Share) pays a fixed amount for every share immediately — the operator bears the variance (and charges a higher fee), and it’s naturally hop-proof. PPLNS pays a slice of actual blocks based on shares in a recent window — the miners bear the luck, but lower fees and the recurring window discourage pool hopping by rewarding sustained contribution.
4. CAN: censor/deprioritize transactions, and direct hashrate toward a chain tip during a fork (also choose transaction ordering). CANNOT: steal your coins (mining never touches keys), or forge transactions / inflate supply. The “cannot” list is enforced because such a block is rejected by every full node independently, so the pool would simply have wasted its work.
5. A pool concentrates who constructs the candidate block (which transactions, in what order), but every full node still independently validates every block, so the rules stay decentralized — a pool can’t make the network accept a rule-breaking block. Stratum V2 pushes back by letting individual miners, not the operator, choose the transactions in the blocks they help find — returning censorship resistance to the people who own the hardware.