How Bitcoin mining pools work: shares, payouts and the pool that started it in 2010

A pool turns a lottery ticket into a paycheck

Mining is a guessing game. Every miner on the network tries hashes until one of them finds a value below the target, and that miner’s block wins the reward. Your chance of winning any given block is your share of the total hash rate. If that share is tiny, you are buying lottery tickets: the expected value is fine, but the payout is rare and lumpy. The Bitcoin Wiki puts numbers on the early version of this problem: a miner running at 1,000 kilohashes per second when the difficulty was 14,484 could expect to wait almost two years for a single block.

A pool fixes the lumpiness, not the odds. Members point their hardware at a coordinator, the pool server, which hands out work. When any member finds a block, the reward goes to the pool, and the pool splits it among members according to how much work each contributed. Nobody’s expected income changes. What changes is that a miner who would have seen one payment every two years sees a small one most days, which is what makes it possible to pay an electricity bill. Our article on how mining works covers the underlying game.

The first pool opened on a forum in November 2010

On 27 November 2010, a BitcoinTalk user called slush, later known by his name Marek Palatinus, opened a thread proposing what he called cooperative mining. His reason was the arrival of graphics-card miners, which had made it nearly hopeless for anyone mining on an ordinary processor to find a block alone. His worked example is the whole idea in one sentence: offer 1,000 khash/s for a day to a cluster running at 20,000 khash/s, and if the cluster finds a block every two days, your cut is 50 divided by 20 divided by 2, or 1.25 bitcoin.

The first replies, the same afternoon, are a nice piece of history. One member, ribuck, objected that pooling changes nothing mathematically, since separate processors have the same combined chance as pooled ones. He was right about the average and missing the point about variance, which is the exact distinction that makes pools worth running. Another, BitLex, backed the plan, noting that even graphics cards took days to find a block on their own. The thread is still live, and the pool it started later ran under the name Slush Pool; its title has been edited over the years to say so.

Shares: proof you did the work, at a difficulty the pool can afford to check

A pool cannot simply take a member’s word for how much hashing they did. So it asks for shares. The Bitcoin Wiki defines a share as a valid proof of work “of the same type as the proof of work that is used for creating blocks, but of lesser difficulty.” A member who submits many shares has demonstrably done many hashes. Occasionally a share happens to meet the real network difficulty as well, and that share is a block. Pool software sets the share difficulty per miner; the Stratum protocol has a message, mining.set_difficulty, for exactly that.

How shares turn into money varies, and the differences are about who carries the risk. Under pay per share, or PPS, the pool pays a fixed amount for every share the moment it arrives, whether or not a block has been found, so the pool bears the variance and the miner gets certainty. Full pay per share, FPPS, does the same but adds an estimate of transaction fees. Slush’s original scheme scored shares so that recent ones counted for more, which discouraged miners from hopping between pools mid-round. P2Pool replaced the coordinator with a chain of shares kept by the miners themselves. Every scheme is a different answer to the same question: when the pool has a lucky or unlucky week, whose week is it?

Who builds the block? getwork, getblocktemplate and Stratum

A pool does more than split rewards. Someone has to assemble the block that everyone is hashing: choose which transactions from the mempool to include, and build the coinbase transaction that pays the reward. In early pools the server did all of it and handed miners a finished header to grind, using a protocol called getwork. As hash rates grew, getwork became a bandwidth problem, and it also meant miners had no say in what went into the blocks their machines were securing.

Two proposals by Luke Dashjr, BIP 22 and BIP 23, both dated 28 February 2012, defined getblocktemplate as a replacement. Instead of a header, the server sends the whole proposed block, which the miner can inspect and, optionally, alter. BIP 23 is candid about why: “There is reasonable concerns about mining currently being too centralized on pools, and the amount of control these pools hold.” Letting miners audit the block before hashing it was meant to loosen that grip.

Later in 2012, Slush released Stratum, a lighter protocol that also replaced getwork but kept block construction with the pool. The Bitcoin Wiki records the tension: Stratum was announced after months of community work on getblocktemplate, and once large pools adopted it, getblocktemplate’s adoption suffered. Stratum has no formal BIP; it became the standard by being used. Its successor, Stratum V2, encrypts the connection, cuts bandwidth and, in the words of Braiins, the company that grew out of Slush Pool, “gives miners the power to choose which transactions they include in a block.”

Pools concentrate a job, not the coins, but concentration still matters

Joining a pool does not hand over your bitcoin; the reward is paid out, and the hardware stays yours. What a pool concentrates is decision-making: which transactions go into blocks and, in the extreme, which chain the combined hash power extends. BIP 23 named that concern in 2012, and it is why the sight of one pool nearing half of the network has set off alarms; the episode is told in our article on the 51 percent attack. Miners can leave a pool in minutes, which is the practical check on any operator.

Measuring pool shares is harder than it looks. Mempool.space, a widely used block explorer, attributes each block to a pool by matching text that pools write into the coinbase transaction and the addresses they pay rewards to, using a public list anyone can correct. Blocks that match nothing are labeled unknown, which the project stresses is a limit of the method rather than a fact about mining. Cambridge’s mining map goes a step further and asks pools to report where their miners connect from; its methodology page says the participating pools represented roughly 32 to 38 percent of total hash rate and that VPN use skews the results, with some countries showing hash rate where “no meaningful mining activities exist.”

For those reasons this article gives no league table. Pool shares move week to week, the identification is partly guesswork, and a number without a date is worthless. If you want today’s picture, read it from a source that shows its method and its date, and remember that a pool’s share is the sum of thousands of miners who can point their machines elsewhere tomorrow.