When miners try to choose a Bitcoin mining pool, the comparison often collapses into a single number: the advertised fee. That approach misses the fact that pools report data differently, credit rewards on different schedules, and apply fees to different parts of the block reward. A spreadsheet built around one fee column will not reveal any of that. A spreadsheet built around a consistent test period, separated data sources, and clearly labeled formulas will.

This article walks through a practical structure for comparing pools using data you can actually export: ASIC dashboards, pool worker pages, and pool earnings ledgers. It does not rank specific pools. Instead, it shows how to organize the numbers so the comparison reflects what each pool actually credited during a defined period, not what a marketing page claims.

Why a Fee Column Alone Is Not a Comparison

Bitcoin's pooled-mining model is built on shares: units of work a miner submits that are easier to find than a full network-valid block, so the pool can measure contribution frequently and allocate rewards accordingly. The Bitcoin developer documentation explains this distinction between the pool's share target and the network's block target, and why shares are not evidence of a mined block by themselves (developer.bitcoin.org). Because shares, payout methods, and reporting windows vary by pool, a spreadsheet needs to separate these inputs rather than blend them into a single score.

Step 1: Choose One Completed Test Period

Pick a period that has already ended, such as 30 completed days, and use the identical start and end dates and time zone for every pool under comparison. Ideally, run the tests in parallel so each pool is being evaluated under the same network conditions during the same calendar window.

Bitcoin mining difficulty is retargeted every 2,016 blocks, roughly every two weeks (blockchain.com). A difficulty adjustment that occurs inside a shared test window does not, by itself, invalidate the comparison because all pools being tested in parallel experience the same network change. The larger problem is testing Pool A and Pool B during different date ranges: even if both tests last 30 days, difficulty, transaction-fee conditions, and total network hashrate may differ between the two periods. If sequential testing is unavoidable, record those network conditions and do not attribute every difference in credited BTC to the pool alone.

For a simple comparison, it is also cleaner to avoid a test period that straddles a block-subsidy halving, since the subsidy portion of the block reward changes at that point even though transaction fees remain separate and variable.

Step 2: Organize the Spreadsheet Into Three Tabs

A workable structure keeps setup information, performance data, and financial data on separate tabs so they are never accidentally merged into one row.

Tab 1 — Pool Terms. One row per pool and payout method: pool name, coin/algorithm, payment method (for example PPS+ or PPLNS), fee and its exact scope, settlement rule, payout threshold, withdrawal fee, stratum endpoint or region tested, and the test start/end dates with time zone.

Tab 2 — Mining Performance. Worker name, number of active ASICs, ASIC dashboard hashrate with its averaging window labeled, pool-reported hashrate with its averaging window labeled, operating hours, uptime as defined by the monitoring source, and accepted/rejected shares for the same worker and period.

Tab 3 — Revenue and Operating Costs. Period dates, BTC credited by the pool's earnings ledger, BTC actually paid out, unpaid balance at the start and end of the period, the BTC/USD reference price and its timestamp, measured average power draw, electricity rate, electricity cost, hosting cost if applicable, and a net operating result.

Whenever possible, assign comparable hardware and hashrate to each pool during the same period. If the tested fleets differ materially in average hashrate or operating time, keep the raw credited BTC but add a separate normalized spreadsheet calculation so unequal work input is not mistaken for a pool-performance difference.

Step 3: Record Payout Method and Fee Scope Exactly as Documented

Do not enter a single "pool fee" figure unless the pool applies one fee uniformly to the entire reward. Payment methods can split the block-subsidy and transaction-fee components differently. As a documented example, ViaBTC's Help Center describes its BTC PPS+ method as applying PPS logic (with a listed 4% fee) to the block-reward component, while transaction fees are allocated under PPLNS logic with a separately listed 2% fee. Its standard PPLNS method applies a listed 2% fee to block rewards plus transaction fees together; after a block reaches six confirmations, the reward is distributed based on the miner's share of pool hashrate over the preceding five difficulty rounds (support.viabtc.com). A spreadsheet that records only "2% vs. 4%" without noting which reward component each fee applies to will produce a misleading headline comparison. Always re-check the exact current fee logic against the pool's own documentation before entering it, since payout rules can change.

Step 4: Separate ASIC Readings, Pool Dashboard Estimates, and Credited Rewards

An ASIC's local dashboard, a pool's worker page, and a pool's earnings ledger measure three different things, and none should be substituted for another. The ASIC reports a device-side reading over whatever window its firmware displays. The pool's worker page shows an estimate derived from valid or accepted shares received by the pool over its own stated window. The earnings ledger records credited rewards under the pool's accounting rules. Label each column with its source and time window so later readers of the spreadsheet do not assume they are the same measurement.

Two formulas are useful here, but both should be labeled as spreadsheet calculations rather than standardized industry metrics, since pools differ in how they classify rejected shares and average hashrate.

Rejection rate, using accepted and rejected shares from the same worker and period:

Rejection rate (%) = Rejected shares / (Accepted shares + Rejected shares) × 100

Treat this as a simple submission-count diagnostic for the same worker and the same pool, not as a standardized cross-pool ranking metric. Pools may use different share-difficulty settings or rejection definitions, so a raw count-based rejection rate should not be compared directly unless the underlying definitions are compatible.

Percentage difference between pool-reported and ASIC-reported hashrate, useful for troubleshooting a connection rather than for ranking pools:

Difference (%) = (Pool-reported hashrate − ASIC-reported hashrate) / ASIC-reported hashrate × 100

This comparison is only meaningful when both readings cover comparable averaging windows; a 5-minute ASIC average compared with a 24-hour pool average will show a divergence that reflects the mismatched windows rather than any real performance issue.

Step 5: Use Credited BTC — Not Withdrawals — for Period Revenue

A wallet withdrawal reflects a payout threshold or a scheduled transfer, not necessarily what was earned in the period under review. A miner may accumulate BTC across a 30-day test but only receive a withdrawal after crossing a threshold, or on a set schedule. To reconcile this correctly:

• Use the pool's earnings ledger, not the withdrawal history, as the primary revenue input for the period.
• Track BTC paid out separately, for cash-flow and reconciliation purposes only.
• Record the unpaid balance at the start and end of the period so any gap between credited rewards and withdrawals is explained rather than left as an unexplained discrepancy.

Step 6: Calculate Electricity Cost and an Estimated USD Result

Once credited BTC and operating costs are recorded separately, the raw figures can be converted into a comparable result.

If the test groups did not contribute matching hashrate for matching operating time, first normalize the credited BTC against the device-side work input. One simple spreadsheet-derived calculation is:

Normalized credited BTC (BTC per PH/s-day) = BTC credited / [Average ASIC-reported hashrate (PH/s) × Operating hours / 24]

This is not a pool-defined or standardized industry KPI. It is only a spreadsheet normalization to prevent a larger or longer-running test group from appearing better simply because it contributed more hashrate-time. Use it only when the ASIC-side hashrate readings are measured consistently across the test groups; a matched parallel test remains the cleaner design.

Electricity cost, using a measured average power draw over the same period as the mining data:

Electricity cost = Average power draw (kW) × Operating hours × Electricity rate ($/kWh)

For USD valuation, use a BTC/USD price with a recorded source and timestamp — for example, a documented historical daily snapshot such as CoinGecko's, which is taken at 00:00:00 UTC (coingecko.com). If one reference price is applied to all BTC credited during the period, the result is a selected-date or period-end mark-to-market value rather than realized USD revenue.

Marked value (USD) = BTC credited × BTC/USD reference price

Combining this with operating costs gives an estimated mark-to-market result:

Estimated USD operating result = (BTC credited × BTC/USD reference price) − electricity cost − hosting cost − other documented operating costs

Label this line "estimated" or "mark-to-market" unless the BTC was actually sold at the reference price. If the goal is instead to estimate USD revenue as it accrued through the test period, apply the same documented daily pricing convention consistently to each day's credited BTC rather than applying one snapshot to the entire period.

Common Errors That Undermine the Comparison

A few recurring mistakes make an otherwise well-built spreadsheet unreliable:

• Comparing a 24-hour ASIC reading against a 30-day pool revenue total.
• Comparing raw BTC credited from test groups that contributed materially different hashrate or operating time without normalizing the work input.
• Treating raw accepted-share counts as comparable across pools that may use different share difficulty settings.
• Subtracting a pool's advertised fee a second time when the earnings ledger already reports rewards net of that fee.
• Adding an electricity-cost line when a hosting invoice already includes power, unless the invoice separately identifies an additional charge.
• Recording pool-estimated hashrate as "accepted hashrate" or inferring device efficiency (J/TH) from pool-side data alone, since efficiency calculations require a matching measured power input, not a pool's work estimate.

When to Refresh the Spreadsheet

A comparison built during one period does not necessarily hold afterward. Consider re-testing after a documented change to a pool's payout method or fee structure, a significant uptime or connectivity event that materially changes the test conditions, or when an older comparison no longer reflects the network environment in which the pools are being evaluated. A routine network difficulty adjustment by itself does not invalidate a properly matched parallel test, although difficulty and transaction-fee conditions should still be recorded when comparing results from different periods.

For readers who want a public reference point for pool-level block share or estimated network hashrate over a defined trailing window, sources such as mempool.space publish this data with selectable periods, which can be a useful cross-check as long as it is kept separate from a miner's own worker and earnings data.

Building the spreadsheet this way takes longer than copying a single advertised fee percentage into a table, but it produces a comparison that reflects what each pool actually credited under matching conditions — and, where necessary, relative to comparable hashrate-time — which is the information that matters when deciding how to choose a Bitcoin mining pool for ongoing operations.

FAQ

Should I compare pools using their advertised fee percentage alone?

No. Fees can apply to different reward components — for example, a pool may apply one rate to the block-reward portion and a different rate to transaction fees under a PPS+ method. Record the fee together with the exact component it applies to, as documented by the pool.

Can I use wallet withdrawal amounts as my revenue figure for the test period?

Not directly. A withdrawal can reflect an earlier balance, a payout threshold, or a transfer schedule rather than the reward credited during the period you are testing. Use the pool's earnings ledger for period revenue and track withdrawals separately for cash-flow reconciliation.

Is it accurate to compare raw accepted-share counts between two pools?

Only if both pools use compatible share-difficulty settings and export definitions, which is often not verifiable. It is generally safer to compare each pool's reported hashrate and credited rewards over the same time window instead of comparing share counts directly.

What should I do if my ASIC's hashrate reading and the pool's reported hashrate differ?

First confirm both readings cover comparable averaging windows, since a short-window device reading will naturally differ from a 24-hour pool estimate. If the windows match and a meaningful gap persists, treat it as a connection or configuration issue to investigate rather than as a performance ranking between pools.

How often should I rebuild the comparison spreadsheet?

There is no fixed universal schedule. Revisit the comparison after a documented change to a pool's payout method or fee structure, a material change in uptime or connectivity conditions, or when the original test period no longer represents the environment you want to evaluate. A normal difficulty adjustment alone is not necessarily a reason to rebuild the spreadsheet if the pools were tested in parallel over the same period.

References

• Bitcoin.org Developer Guide, "Mining"
• Blockchain.com, "Bitcoin Difficulty"
• ViaBTC Help Center, "How are profits calculated"
• CoinGecko API Documentation, "Coin Historical Data by ID"