Choosing a mining pool: what the payout schemes actually mean

A single machine will almost never find a block. Pooling combines your hashrate with everyone else's so that payouts arrive steadily rather than once a decade. What differs between pools is not the mining, it is who carries the luck, and that is decided entirely by the payout scheme.

PPS, pay per share

The pool pays you a fixed amount for every valid share you submit, whether or not the pool finds a block that day. Your income becomes a smooth function of your hashrate. The pool absorbs all the variance and charges a higher fee for doing so. For an operator with fixed monthly costs and a lender to satisfy, that predictability is the product.

FPPS, full pay per share

The same idea extended to transaction fees. Plain PPS pays you your share of the block subsidy only. FPPS adds an average of the network transaction fees over a recent window, so you are paid for the fee revenue too. In periods where fees are a meaningful part of block rewards, that difference is real money, and it is why FPPS has become the default expectation for larger operators.

PPS+ and PPLNS

PPS+ pays the subsidy as PPS and the transaction fees as actually earned, so fees follow the pool's real luck while the subsidy stays smooth. PPLNS, pay per last N shares, pays only when the pool finds a block, distributed over recent shares. Fees are lower and the expectation over the long run is usually slightly higher, but the payouts are lumpy and you carry the variance.

The rule of thumb: if the mining income has to cover a fixed electricity bill and a loan payment every month, take the smooth scheme and pay for it. If you have reserves and a long horizon, PPLNS keeps more of the upside.

What else to compare

• Fee, stated properly. A one percent difference on a fleet grossing thousands a day is not small. Ask what the fee applies to, subsidy only or subsidy plus fees.
• Payout threshold and frequency. Daily payouts above a low threshold are normal. A high threshold quietly lends the pool your balance.
• Where the pool is. Latency raises stale share rates. A pool with a server near your site loses you less.
• Custody. Your payout address should be yours. A pool holding balances is a counterparty, and counterparties fail.
• Transparency. Published luck, block history and statistics per worker. If you cannot audit the pool's luck, you cannot tell bad luck from a bad pool.

Stale shares and the part nobody watches

A share submitted after the network has moved on earns nothing. Stale rates below about one percent are unremarkable, above two percent something is wrong: latency, an overloaded switch, a bad firmware setting or a pool with poor infrastructure in your region. It is worth checking in the first week and then monthly, because it degrades silently and nobody notices until someone compares the pool dashboard against the expected output from hashprice.

Failover, and why two pools

Every miner accepts several pool entries. Configure at least two, ideally with different operators, and test the failover by blocking the primary rather than assuming it works. A pool outage with no failover is an outage of your whole revenue, and it happens often enough to plan for. Set this up during commissioning, alongside everything else in the first 72 hours.

Concentration, briefly

Choosing a pool is also a small vote on how concentrated Bitcoin's hashrate is. When one pool grows very large, the network's security argument weakens for everyone, including you. It costs nothing to prefer a smaller pool with comparable terms, and it is one of the few decisions where the operator's private interest and the network's interest line up.