What is a Mining Pool?
A Bitcoin mining pool is a work coordinator for proof-of-work. Many ASIC operators submit their hashrate to one service. The pool builds block candidates, splits the search space, and redistributes the reward under published rules when a valid block is found. Nothing is physically merged: you point the miner at a server, usually over Stratum, and receive a stream of jobs.
Why solo is rarely viable at small scale
Finding a Bitcoin block is a random process, each hash carrying a tiny chance of beating the network target. Expected time between blocks for a given hashrate scales with difficulty divided by that hashrate.
In practice, an operator who represents a negligible fraction of global hashrate can wait months, years, or never see a block across an ASIC's useful life. A pool does not change long-run expected value, aside from fees and connection quality. It changes variance: many small regular payouts instead of a rare, massive one.
How work is shared
The pool builds a block template, with its transactions, coinbase, and version, then splits it into nonce and extra-nonce ranges. Each miner searches a distinct slice, which prevents duplicated work.
When an ASIC finds a hash hard enough for the pool's share target, easier to hit than the network target, it submits a share. That share proves work was done. If a share also meets the network target, the pool broadcasts the block.
Shares therefore act as the work counter, and payout schemes, FPPS, PPLNS, PPS, or their variants, turn those shares into satoshis. Formulas differ between pools: the payout page of the pool you use is what binds.
What the pool does, and what it does not
A pool handles five functions: coordination through its Stratum servers, worker authentication, and job dispatch; block construction, with its transaction selection policy; fast propagation of a found block to reduce orphan risk; accounting, with share tallies, balances, and payout thresholds; and infrastructure, meaning points of presence, failover, and monitoring.
It handles neither power, nor cooling, nor the firmware on your machines. A pool-side outage stops your effective contribution while your fans keep spinning, which explains part of the gap between local hashrate and paid hashrate.
A pool also guarantees neither a block nor a profit. Bitcoin price, your electricity rate, your ASIC's efficiency, and network difficulty set the margin between them. And it is not mandatory custody: most pools pay to an address you control, subject to a minimum payout threshold.
Why small hashrate joins a pool
Three reasons dominate for operators of one or a few ASICs.
Revenue smoothing. A regular stream, daily or near-daily depending on scheme and threshold, pays the electricity bill as it arrives and lets you track real cost per TH/s.
Treasury. Waiting for a full solo block ties up capital and exposes you to a difficulty retarget, a hardware failure, or a forced sale before the first payout.
Operations. A mature pool provides failover URLs, per-worker statistics, and sometimes an API. That does not replace local monitoring, but a silent worker shows up immediately on the pool side.
The cost of that aggregation is a fee, detailed in the pool fees article, and a form of lock-in: shares already submitted generally do not travel with you if you switch pools.
Five checks before connecting an ASIC
- The payout scheme and its documentation page, so you know how your shares become satoshis and how often.
- The advertised fees, separating the pool commission from any transaction fees withheld on payouts.
- The geographic servers available, choosing the closest point of presence to limit latency and stale shares.
- The protocol supported, Stratum V1 or V2, checking that your firmware speaks the same dialect, since otherwise negotiation simply fails.
- The worker naming rules and the minimum payout threshold, which determine when you actually receive anything.
Always configure at least one backup pool. And watch the stale or rejected share rate from the first days: a high figure points at latency, a wrong URL, or a firmware setting, never at luck alone.
For hashrate that is small against the network, the pool is the default tool. For a very large fleet, the choice between solo and pool becomes a question of tolerable variance, template control, and treasury.
Buy or compare through The Bitcoin Bay
The Bitcoin Bay is an independent business introducer: we list new ASICs sourced directly from manufacturers (Bitmain, MicroBT, Bitdeer, Canaan) and refurbished machines via verified reseller partners. Each model is paired with professional hosting options at our partner sites in Northern Europe and Paraguay.
No yield promises, no payment handled on our side — the transaction is signed directly with the chosen partner. CIF/AMF status not solicited.
Related reading
Monitoring a Miner: Tools and Metrics
Monitoring a miner means comparing what the machine reports to what the pool counts. The six families of signals to track, and how to read them without blaming the wrong cause.
ReadBitmain Logs and Kernel Panic: Diagnostics
Read a Bitmain controller's logs in time order, sort the motif into five families, and treat a kernel panic as a controller halt rather than a mining problem.
ReadStratum Jobs and clean_jobs
A Stratum job is a work contract, and the clean_jobs flag revokes it. The five causes of invalidation and what you can actually fix.
Read