Selecting a Bitcoin mining pool is often reduced to a single question: which pool charges the lowest fee? To choose a Bitcoin mining pool, compare its reward-allocation rules and fees, connection quality, monitoring tools, withdrawal conditions, and account-security controls. This guide reviews eight mistakes that new ASIC operators commonly make when evaluating pools, and explains the terminology and mechanics a beginner needs to check before pointing hashrate at any single endpoint.

Mistake 1: Comparing Pools by Headline Fee Alone

A pool's advertised fee percentage does not describe the full picture unless the reader also knows which reward component it applies to, which payout method it assumes, and whether withdrawal conditions add further cost. Since the April 2024 halving, the Bitcoin block reward has consisted of a 3.125 BTC subsidy plus variable transaction fees, so how a pool allocates the transaction-fee portion of a block reward materially affects realized income, independent of the headline fee figure.

Some pools apply a single fee across the entire reward; others apply different fees to the subsidy and the transaction-fee components. A beginner should confirm, for the specific coin and payout method under consideration, exactly what the stated fee covers, whether withdrawal fees apply separately and what minimum-payout thresholds govern payment timing, and whether the comparison being made uses the same time period and payout model for every pool under review.

Mistake 2: Not Understanding Payout Methods Before Connecting

Mining pools use different reward-accounting methods, and these change the timing and variance of credited rewards rather than the underlying probability that a miner's work is valid. The commonly used methods are:

• PPS (Pay Per Share): rewards are calculated from valid shares submitted under the pool's defined rules, independent of whether the pool itself finds a block in a given period.
• FPPS (Full Pay Per Share): extends the PPS calculation to include an estimated transaction-fee component alongside the block subsidy, under the pool's published formula.
• PPS+: a hybrid approach in which the block-subsidy portion is typically paid under PPS-style logic while the transaction-fee portion follows a separate method, often PPLNS. Exact implementation varies by pool.
• PPLNS (Pay Per Last N Shares): rewards are allocated based on work contributed within a defined recent share window, and only when the pool actually finds an eligible block, which introduces more short-term variance than PPS-based methods.

As ViaBTC's current Help Center documentation illustrates, its PPS+ method applies a 4% fee to the PPS-calculated block-subsidy component and a 2% fee to the PPLNS-calculated transaction-fee component, while its PPLNS method applies a flat 2% fee to both components; PPLNS rewards are also calculated over the last five difficulty rounds and require six block confirmations before crediting (ViaBTC Help Center). This is a documented example of one pool's current rules, not a universal definition, and beginners should verify the equivalent rules for any pool they are considering before assuming two pools' "PPS+" offerings are identical.

The underlying mechanism that makes any of this possible is the pool share: a pool sets a share target that is easier to satisfy than the Bitcoin network's block target, so miners submit shares frequently, and the pool measures contributed work from those shares rather than waiting for an actual block to be found (Bitcoin Developer Guide). No payout method eliminates the dependence of mining income on network difficulty, transaction-fee conditions, pool fees, and the miner's own uptime; it only changes how that income is smoothed over time.

Mistake 3: Confusing Local ASIC Hashrate With Pool-Estimated Hashrate

An ASIC's local hashrate reading comes from the device's own firmware. A pool's displayed hashrate is an estimate derived from shares submitted and accepted over a defined period. These are related but not interchangeable measurements, and short-term gaps between them are expected rather than evidence of a problem.

Differences commonly arise from mismatched averaging windows, the normal randomness of share submission, intermittent connectivity, rejected shares, or inaccurate tuning on the device itself. A beginner comparing the two figures should use comparable windows — several hours or a full day rather than a few minutes — before concluding that a pool is undercounting contributed work. If a gap persists over a matched window, the next step is to review the pool's rejected-share breakdown and the miner's connection logs rather than assuming the pool's estimate is simply wrong.

Mistake 4: Ignoring Rejected and Stale Shares

A pool can only credit work that it accepts under its own validation rules. Rejected shares form the broad category; stale shares, invalid shares, and duplicate shares are specific reasons a share may fall into that category, not separate metrics that stand apart from it. A rising rejection rate can result from delayed job updates, unstable connectivity, hardware errors, aggressive tuning, firmware issues, or repeated submissions. The rejection reason helps determine what to investigate.

Before switching pools in response to a short-term revenue difference, review the rejection breakdown shown on the pool dashboard against the miner's own logs:

• Stale shares: check network latency, connection stability, and delays in receiving updated mining jobs.
• Invalid shares: check overclocking, temperature, power stability, firmware, and hardware errors.
• Duplicate shares: check software or proxy configuration and repeated submissions after reconnects.

These checks follow the distinctions in ViaBTC's rejected-share guide.

A connectivity issue between the ASIC and the pool endpoint can produce results that look like a pool-performance problem but are, in fact, a local network or configuration issue. Acceptable rejection levels vary by ASIC model, firmware, share difficulty, and network distance to the pool's endpoint, so a single universal threshold is not a reliable benchmark.

Mistake 5: Using Outdated or Unofficial Stratum Addresses

A Stratum address is the network destination the ASIC uses to receive mining jobs and submit shares; it is not a payout wallet address, and the two should never be confused. Beginners sometimes copy an endpoint from an old video, forum post, or screenshot that applies to a different coin, region, or account configuration, which can cause failed connections, rejected shares, or workers being credited under the wrong account.

ViaBTC's current connection guidance recommends copying the pool URL, port, and worker-name format directly from the pool's live configuration page immediately before setting up a device, and matching the endpoint to the correct coin and algorithm (ViaBTC: mining pool Stratum address explained). This is a reasonable practice for any pool, not only ViaBTC, since connection details can change over time.

Mistake 6: Skipping Backup Pool Configuration

Most mining firmware supports multiple pool entries, typically a primary connection and one or more alternate connections. Where this is available, configuring and testing a backup entry can reduce downtime if the primary connection becomes unreachable from the miner's network. This is not a guarantee against every outage; the backup entry still needs to be correctly configured, compatible with the firmware, and periodically checked to confirm it actually accepts the switch when needed.

Beginners frequently leave secondary pool fields blank or fill them with placeholder values, which removes any practical benefit from the feature. Where firmware supports multiple entries, it is worth setting a working backup configuration rather than assuming the primary connection will remain available indefinitely.

Mistake 7: Equating Pool Size or Pool Luck With Better Returns

Larger pools find blocks more often simply because they represent more aggregate hashrate, but that does not mean an individual miner necessarily earns more under a given payout method, after fees, and under their own specific connectivity conditions. As of October 8, 2026, at 11:41 a.m. UTC+8, Mempool.space's mining pool rankings showed 1,042 blocks in the trailing one-week (1W) window. Foundry USA accounted for 279 blocks (26.78%) and AntPool for 213 blocks (20.44%), together representing 47.22% of blocks in that window (Mempool.space mining pool rankings). Figures like these describe a short, time-windowed concentration of blocks found, not a ranking of payout terms, connection quality from any particular miner's location, or account protections.

Pool luck — the ratio of blocks actually found to blocks statistically expected over a stated period — is a historical measure, not a forecast. Under block-dependent methods such as PPLNS, shorter measurement windows can show considerable variance even for a large pool, so a single week of favorable or unfavorable luck says little about expected results over a longer period.

Mistake 8: Overlooking Withdrawal Rules and Account Security

Choosing a pool also means choosing the path by which credited rewards eventually reach a miner-controlled wallet. Before committing hashrate, it is worth reviewing the minimum payout amount, payout frequency, any withdrawal fees, available payout networks, and whether the pool restricts or delays changes to the withdrawal address. Two-factor authentication and account-recovery procedures are separate from mining-connection settings but are equally relevant, since a pool can accept shares correctly while a user's account remains inadequately protected.

These settings are independent of the payout-method mechanics discussed earlier: a miner can have correctly configured PPS+ or PPLNS accounting and still experience friction or risk at the withdrawal stage if these account-level details are not reviewed in advance.

A Practical Checklist Before Connecting Hashrate

The following points summarize the mistakes above into questions a beginner can check before directing hashrate to a pool:

• What does the pool's documentation say its payout method (PPS, PPS+, FPPS, or PPLNS) actually covers, including the transaction-fee component?
• Does the advertised fee apply to the block subsidy, transaction fees, or both, and is it the same across payout methods?
• Is the Stratum address current, matched to the correct coin and algorithm, and copied from official documentation?
• Does the firmware support a backup pool entry, and has it been tested?
• Are rejected-share reasons visible, and have they been compared against the miner's own logs?
• Are local and pool-side hashrate figures being compared over the same time window?
• What are the minimum payout threshold, payout schedule, and any withdrawal fees?
• What account-security and recovery options does the pool provide?

The pool that best fits a given operation is not necessarily the one with the largest share of recent blocks or the lowest advertised fee; it is the one whose payout rules, connection quality, monitoring tools, and withdrawal settings match the miner's actual setup and risk tolerance.

FAQ

Is the pool with the lowest fee always the cheapest to use?

Not necessarily. The fee may apply only to part of the reward, such as the block subsidy, while a separate fee or accounting method applies to transaction fees. Withdrawal fees can reduce the amount received, while a minimum-payout threshold usually delays payment rather than deducting mining rewards. Compare reward-accounting costs and payment timing separately.

What is the difference between PPS+ and PPLNS?

PPS+ is typically a hybrid method that pays the block-subsidy portion under PPS-style logic and the transaction-fee portion under a separate method, often PPLNS, while PPLNS allocates both reward components based on work contributed within a recent share window, only when the pool finds an eligible block. Exact rules, fees, and accounting windows vary by pool and should be confirmed in each pool's current documentation.

Why does my ASIC show a different hashrate than the pool dashboard?

Local hashrate is read from the device, while pool-side hashrate is an estimate based on shares accepted over a defined period. Short-term differences are normal due to averaging-window mismatches and the probabilistic nature of share submission; persistent differences over a matched time window warrant a check of rejected shares and connection stability.

Should I always choose the largest mining pool?

Not automatically. Pool size affects how often the pool as a whole finds blocks, but it does not determine an individual miner's fee, connection quality, withdrawal terms, or account protections, all of which should be reviewed independently.

How often should I check a pool's payout and fee documentation?

Because fees, accounting windows, and withdrawal rules can change over time, it is reasonable to review a pool's current official documentation before initial setup and periodically afterward, rather than relying on settings observed in an older guide or video.

References

• Bitcoin Developer Guide, "Mining"
• Mempool.space, "Mining Pool Rankings" — 1W window accessed October 8, 2026, at 11:41 a.m. UTC+8.
• ViaBTC Help Center, "How Are Profits Calculated"
• ViaBTC, "Mining Pool Stratum Address Explained"
• ViaBTC, "Why Are My Mining Shares Rejected?"