Mining Pool

Anna has one mining machine. She pays for electricity every day, but mining alone she might wait a very long time for her own block. If she finds a block the network accepts, its reward is hers; until then she receives nothing from this mining. Waiting a long time does not mean a win is now close. Under unchanged conditions, each new attempt has the same chance. In a pool, her machine works alongside others. The pool can reward a miner who did not find a particular block because it measures contributions and uses an agreed payout model. Anna gives up keeping the entire revenue from her own block in exchange for smaller, generally steadier income. This does not reduce network difficulty or create extra rewards. The pool also usually charges a fee. Whether income covers electricity and equipment is a separate question. [6] [7]

The pool cannot see every calculation Anna's machine performs. It nevertheless needs to verify that the machine is working and estimate its contribution. So it sets an easier condition than the Bitcoin network. A result meeting that condition is called a Mining Share, or share. The machine can report verifiable results regularly even without finding a block. From accepted shares and their difficulty, the pool statistically estimates work. It does not count every attempt exactly. If two devices have different share difficulties, their raw submission counts cannot be compared directly. An ordinary share does not create a Bitcoin block or a payment confirmation. Only a rare result also meeting the network condition allows a block to be submitted, and the block must pass the other checks too. A share is evidence of work for the pool, not a piece of bitcoin the machine has just produced. [7] [9]

Anna can connect the same machine to different pools and see different reward patterns. The accounting model is one reason. PPS, Pay Per Share, credits a predetermined expected value for an accepted share according to its difficulty. Anna need not wait for her pool to find a lucky block: the operator absorbs the risk of random variation in discoveries. This neither guarantees the operator can always pay nor creates a fixed hourly wage. Share counts and mining conditions still change. FPPS, Full Pay Per Share, typically adds estimated transaction fee revenue to the expected share of newly issued bitcoin. PPLNS, Pay Per Last N Shares, instead distributes revenue from blocks actually found according to work within a specified recent window. Rewards therefore depend more on the pool's current luck. Its rules define that window; it need not simply mean the last hour. The abbreviation alone is not enough for comparison. Fees, estimation methods, window length and treatment of blocks left outside the main history, called Stale Block, also matter. The reward model determines entitlement and calculation; the transfer schedule to a wallet is a separate rule. [7] [8]

Anna sees a growing balance in her account. Until it reaches her wallet, she relies on the pool to account for it correctly and pay it out. She needs to know when payment occurs, whether a minimum balance is required, what fees apply and which address receives it. Services differ: automatic reward credits do not necessarily mean immediate transfers. Operations matter too: accepted and rejected shares, their difficulty called Share Difficulty, server availability and backup connections. Firmware is the miner's control software and must work with the pool. Comparing longer-term pool records with her own operational logs and actual payments helps identify discrepancies. Found blocks can be checked on the blockchain, but it cannot reveal the pool's entire internal accounting. The ability to switch pools and knowing who selects transactions are also important. [8] [9]

If a job changes before a result arrives, the pool may no longer credit it. Latency here means the communication delay between the device and the pool. A share can be rejected as stale, duplicate, malformed or inconsistent with its assigned job. Higher miner-to-pool latency, slow job updates and network outages increase wasted work. The proportion of stale shares therefore indicates the operational efficiency of the miner’s connection to the pool; it is not the same as a Stale Block in the blockchain. [9]

The block reward is recorded in a special first transaction called the Coinbase Transaction. Its outputs specify amounts and the conditions for spending them later. The reward can therefore go to one or several recipients. A Block Template is the proposed block, including selected transactions. In a conventional pool, the pool operator usually constructs the Block Template and determines the recipient of the coinbase output. The miner mainly tries different values within its assigned job, looking for a result that meets the network’s condition. This gives the pool influence over transaction selection, not the ability to force acceptance of an invalid block; every Full Node checks the block independently. A Full Node is software that verifies blocks and transactions against Bitcoin’s rules. [6] [10]

Besides payout size, it matters who decides which payments enter blocks. Excluding particular transactions can delay their confirmation. Pool concentration matters because a small number of coordinators can influence transaction inclusion, software deployment and the short-term distribution of Hashrate, the number of mining calculations per second. Pool Hashrate is not the same as ownership of mining equipment: operators of specialized mining machines, called ASICs, can connect them to another pool. Risk increases when switching costs, contracts or firmware restrict that ability. [6] [10]

Stratum is a set of rules for communication between miner and pool. Encryption protects messages in transit, while authentication helps verify the other party. Stratum V1 assigns mining work, with template control usually remaining at the pool. Stratum V2 separates roles more clearly and supports encrypted, authenticated communication. Its optional Job Declaration Protocol lets miners submit their own template with their own transaction selection when both miner and pool support the necessary components. Stratum V2’s Mining Protocol can run without this feature, so the Stratum V2 label alone does not guarantee independent transaction selection. [10]

For readers interested in the mechanics: a Block Template is a proposed block's contents. A worker identifies a connected mining device or an account under which the pool records its work; a header is a compact record of block information. A mining job comes from a Block Template or an equivalent construction of a candidate block. BIP22 describes getblocktemplate, and BIP23 extends it for pooled mining. The pool protocol passes the required fields, coinbase transaction data and search space to workers. An ASIC Miner tries different headers and calculates their hash, a numerical fingerprint. To satisfy Proof of Work, the evidence of computational effort, this hash must be less than or equal to the network threshold called the target. The block must also meet Bitcoin’s other rules. [1] [2] [5]

Technical detail: target is a numerical threshold that the hash, the mining calculation's result, must not exceed; equality also qualifies. VarDiff means variable share difficulty. A pool sets an easier share target to receive results frequently enough for measurement. Bitcoin’s network target is much harder to satisfy. An accepted share meeting only the pool target counts under the pool’s reward rules; if the same hash also meets the network target, a candidate block can be submitted. VarDiff changes share difficulty and thus submission frequency, not Bitcoin’s consensus Difficulty. [9]