
A mining pool combines hashrate from many miners and divides earnings through methods such as PPS, PPLNS and FPPS. The chosen method determines who carries short-term mining variance, how rewards are calculated and what fee the operator charges.
A mining pool coordinates many miners as one block-finding group. Each machine receives work from the pool and returns proofs of completed hashing. If the pool finds a valid block, its payout method divides eligible proceeds among participating miners.
A solo miner receives the entire reward after finding a block. The drawback is variance: a small operation may wait much longer between payments. Pooling the same hashrate produces smaller payments more often because the group tests more hashes per second.
The operator prepares jobs, validates shares, submits valid blocks and calculates balances. It does not own the contributed hardware. Miners can redirect their machines by changing the connection settings.
Pooling mainly changes payout variance. It does not make an individual hash more likely to satisfy the network target.
The practical difference is cash flow. A miner with fixed electricity bills may prefer frequent payouts, even when a service fee reduces net revenue.
A share proves that a miner completed work meeting the pool’s target. It usually does not meet the harder network target required for a block. Shares let the pool measure each miner’s contribution.
| Measurement | Hypothetical difficulty | Expected result |
|---|---|---|
| Pool share target | 10 | One accepted share per unit of pool work |
| Network block target | 1,000 | One network-valid result per 100 pool shares |
| Miner contribution | 400 of 10,000 accepted shares | 4% of measured pool work |
These numbers are illustrative. Pools can adjust worker difficulty so fast machines do not flood the server. The same mechanism lets slower machines report work often enough for measurement.
Suppose one miner submits 400 valid shares while all workers submit 10,000 shares of equal difficulty. The pool records a 4% contribution for that interval. With variable difficulty, the pool must compare the work represented by each share instead of counting submissions alone.
When a submitted result also passes the network target, the pool sends the block to the network. The payout method determines how recorded work becomes a miner balance.
Mining pool payout methods determine who carries the cost of unlucky block discovery. PPS shifts most short-term variance to the operator. PPLNS leaves more of it with miners. Other methods change how transaction fees, round timing and block ownership affect payment.
| Method | Payment basis | Miner variance | Payment pattern |
|---|---|---|---|
| PPS | Each accepted share | Low | Steady |
| PPS+ | PPS subsidy plus variable transaction fees | Low to medium | Mostly steady |
| FPPS | Expected subsidy and transaction fees per share | Low | Steady |
| PPLNS | Work inside the last-N-shares window | High | Variable |
| PROP | Work submitted during the current round | High | Variable |
| SOLO | Reward assigned to the block finder | Very high | Rare |
| SCORE | Time-weighted shares | Medium to high | Variable |
PPS and PPLNS are pool payment schemes, not mining algorithms. FPPS adds an expected transaction-fee component to PPS. PPS+ commonly uses PPS for the subsidy and a variable formula for transaction fees.
PROP rewards work inside one round. SCORE gives shares a time-dependent weight, which can discourage miners from switching pools based on round timing.
A payout method does not create more block rewards. It distributes variance, timing risk and fee uncertainty between miners and the operator.
PPS assigns a stated expected value to every valid share. Payment does not depend directly on whether the pool finds a block during the same accounting interval. The operator therefore needs reserves for unlucky periods.
Consider a hypothetical pool that prices a three-unit block component across 100,000 equal-difficulty shares. Before fees, the expected value of one share is:
3 ÷ 100,000 = 0.00003 units
A miner who submits 1,000 accepted shares receives 0.03 units under this example. The calculation does not change if the pool finds no block during that interval.
PPS+ separates reward components. It prices the block-subsidy component per share, then distributes transaction fees under the pool’s published formula. Transaction fees vary between blocks, so the complete PPS+ payout is not fully fixed.
PPS can suit miners who value stable cash flow. Its fee needs to be weighed against the cost of carrying electricity and hosting expenses through an unlucky period.
PPLNS distributes a pool-found reward according to work recorded in a rolling share window. A miner receives no reward for an interval in which the pool finds no qualifying block. Payments can therefore fluctuate even when the miner’s hashrate stays steady.
A simplified example uses a window of 10,000 equal-difficulty shares. If one miner contributes 250 shares, that miner supplies 2.5% of the eligible work. A distributable reward of three units would assign 0.075 units to that work.
The calculation is:
250 ÷ 10,000 = 2.5%
3 × 2.5% = 0.075 units
Two equal work periods can produce different payments because block discovery is random.
The rolling window also reduces the benefit of pool hopping. Nobody knows when a block will appear, and older shares can leave the window. Continuous mining keeps a larger portion of recent work eligible.
These methods divide mining variance in different ways. Selection also depends on how a pool handles transaction fees, stale shares and orphaned blocks.
FPPS prices both the block subsidy and an expected portion of transaction fees. The operator pays per accepted share and carries short-term differences between expected and actual rewards.
PROP divides a found reward according to shares submitted during one round. A long round leaves more shares competing for the reward. A short round leaves fewer.
SOLO uses pool infrastructure but assigns the distributable reward to the miner whose work found the block. Other participants receive no part of that block through the SOLO scheme.
SCORE gives shares a time-dependent weight. The exact weighting formula depends on the operator’s published rules.
A pool fee reduces mining revenue. A payout threshold determines when accumulated earnings become eligible for withdrawal. Both terms affect cash flow.
Two documented examples show how differently operators state these terms. Foundry USA Pool publishes a regular minimum withdrawal threshold of 0.01 BTC but states no fee on that page. F2Pool’s Bitcoin guide states its fee twice over, because the fee depends on the method: 4% for FPPS and 2% for PPLNS — one pool, one hashrate, two prices for two different products.
Current fees and schemes for every Bitcoin pool we track sit on our Bitcoin pool page, updated as the operators change them. This article doesn’t reproduce that list: a fee printed here goes stale within weeks and would then disagree with our own live page.
The cited Foundry page describes 0.01 BTC as its regular minimum withdrawal threshold. F2Pool’s Bitcoin guide lists 4% for FPPS and 2% for PPLNS. Operator terms can change, so the pool’s current documentation remains the reference before connecting hashrate.
A payout threshold does not change the amount of work recorded by the pool. It controls when the balance can be sent. Another relevant term is the blockchain transaction fee: the pool may absorb it or deduct it from a withdrawal.
Net wallet receipts matter more than the advertised pool fee alone. The payout method, threshold, rejected shares and withdrawal costs all affect the result.
Stratum connects mining hardware or software to a pool through a two-way TCP connection. The pool sends the information needed to construct work and specifies its share target. The miner returns completed work for validation.
Each coin, region and connection mode may use a different endpoint. The correct host and port come from the operator’s current documentation.
account.rig01.A configuration can look like this:
URL: stratum+tcp://pool.example.com:3333 Worker: account.rig01 Password: x
The password format depends on the pool. Separate worker names make offline or underperforming machines easier to identify.
The guides to Stratum addresses and worker setup and server versus client mining pool software provide more configuration detail.
Hashrate concentration can weaken a mining network’s decentralization because one operator coordinates a large portion of block production. Pool rankings estimate concentration from identified blocks. They do not directly identify every machine owner.
Short measurement windows also include mining luck. Their block shares should be read as estimates rather than an exact census of physical hashrate.
In 2014 the GHash.io pool briefly controlled more than half of Bitcoin’s computing power. The pool answered the alarm with a voluntary commitment not to exceed 40% of the network’s hashrate — a promise, not a protocol rule, which is exactly why pool concentration is still watched.
Majority processing power lets an operator prevent some or all transactions from gaining any confirmations, and reverse transactions it sent itself while it holds that majority. It does not let that operator send coins that never belonged to it, or reverse other people’s transactions without their cooperation.
A large pool is not automatically attacking the network. The concern is the amount of block-production power coordinated by one operator.
Miners can distribute hashrate among different operators or use arrangements that give them more control over block construction.
PPS or FPPS can fit miners who prioritize predictable cash flow. PPLNS can fit miners who stay connected for long periods and can absorb uneven payments. No method fits every operation.
The comparison should cover four questions:
Small miners may find that time to threshold matters more than a small fee difference. Larger operations can compare long-run PPLNS variance with the price charged for PPS stability.
Use the mining pool directory to shortlist operators, verify their current terms and test one worker before moving the rest of your hashrate.
PPS assigns a calculated amount to each accepted share, independent of short-term pool luck. The operator carries most short-term variance. PPLNS pays from pool-found blocks and calculates each miner’s portion from work inside a rolling share window.
A share proves that a miner completed work meeting the pool’s easier target. It lets the pool measure contributed hashing work. Some shares also meet the harder network target and can produce a block.
Fees depend on the coin, payout method and account terms. F2Pool’s cited Bitcoin guide lists 4% for FPPS and 2% for PPLNS. The operator’s current documentation is the final reference because pricing can change.
Enter the pool’s official Stratum host and port in the miner configuration. Add the required account or wallet identifier and a worker name. After starting the miner, confirm accepted shares on the pool dashboard.
A pool can coordinate a majority if miners direct enough hashrate to it. GHash.io briefly crossed that level in 2014 and then pledged to stay under 40% of the network. Majority control enables transaction censorship and reversal of the attacker’s own recent transactions, but not spending coins that were never its own.