Why a Difficulty Epoch Is a Useful Observation Window
A single dashboard screenshot or one payout cycle says very little about how a mining operation is actually performing. Bitcoin's network difficulty, by contrast, stays fixed between retargets, giving miners a consistent reference period against which local hardware data, pool-reported data, and settlement records can be compared. The Bitcoin protocol adjusts difficulty every 2,016 blocks, targeting a two-week interval of 1,209,600 seconds based on an average 10-minute block time, though the actual elapsed time varies with real block discovery (Bitcoin Developer Guide).
Using a full difficulty epoch as the observation window has one important limitation that should be stated upfront: it does not turn mining into a controlled experiment. Block arrivals remain probabilistic, pool luck can vary between epochs, transaction-fee income can fluctuate, and a pool's dashboard often reports hashrate as a short rolling average rather than an epoch-long figure. An epoch benchmark is best understood as a disciplined way to organize data collection, not as a method that removes randomness from mining outcomes.
Setting the Benchmark Boundaries
Define the epoch by consensus events, not by the calendar. Use the block height at which a new difficulty takes effect as the start point, and the next retarget as the end point. Record the following before data collection begins:
- Epoch start and end block heights, with timestamps
- The difficulty value in force during the period
- Actual elapsed time between the two retargets
- The mining endpoint, region, and payout method in use
- Any planned firmware, frequency, cooling, or configuration changes
Calendar-month comparisons are weaker for this purpose because a single month can span parts of two or three difficulty periods, each with a different expected reward per unit of hashrate. Aligning the observation window to the epoch avoids blending different network difficulty settings into one baseline, though it does not by itself make two separate epochs directly comparable — differences in difficulty, duration, transaction-fee conditions, and fleet configuration must still be accounted for separately.
Separating the Four Data Layers
A sound benchmark keeps four categories of data distinct rather than merging them into a single stability figure. A miner can have stable ASIC telemetry but a poor connection to the pool, or a stable connection but variable PPLNS income driven by pool luck and network fee conditions. Collapsing these into one score obscures the actual cause of any variance.
ASIC and Site Performance
This layer covers local hashrate, uptime, temperature and fan behavior, hardware faults, and, where available, on-site power measurements. These figures should come from ASIC firmware, farm-management software, or site monitoring — not from the pool dashboard. Local hashrate is a device-reported or locally measured figure; it answers what the hardware itself is producing, independent of how the pool later estimates that output from submitted shares.
Connection and Share Handling
This layer covers pool-reported worker hashrate, accepted and rejected shares, stale-share data where the pool separately reports it, endpoint changes, and reconnect events. A pool sets its own share target, which is normally a numerically higher (and therefore easier) target than the Bitcoin network target; shares that meet this pool target are used to measure each miner's contribution for accounting purposes (Bitcoin Developer Guide — Mining). Rejected shares are the umbrella category; stale, invalid, and duplicate shares are subcategories where a pool reports them separately, and they should not be added on top of a total rejection figure that already includes them.
Settlement Results
This layer covers credited BTC, payout timing, and the payout method in force — PPS+, PPLNS, or another documented scheme — since each carries a different relationship between shares submitted and rewards credited. Settlement data should be reconciled against the pool's own documented rules rather than treated as a direct proxy for connection quality.
Network Conditions
This layer covers the difficulty in force during the epoch, the epoch's actual duration, and block-timing behavior. It provides the fixed backdrop against which the other three layers are interpreted, and it is the one layer largely outside the miner's or pool's control. If a block-subsidy halving occurs within the observation epoch, reward analysis should treat the pre-halving and post-halving portions separately rather than assuming reward conditions were constant throughout the full period.
Core Metrics and How to Calculate Them
A few calculations are useful once the four data layers are separated, provided the inputs come from compatible measurement windows.
Rejection rate. If accepted and rejected shares are measured at the same share difficulty or normalized under the same accounting method, the standard raw-count calculation is:
Rejection rate = Rejected shares ÷ (Accepted shares + Rejected shares) × 100
Use the pool's own displayed rejection rate where available, and note its reporting window. If share difficulty changes during the observation period, raw share counts no longer represent equal amounts of work across the full epoch. In that case, prefer the pool's own rejection-rate metric or difficulty-weighted work data where available rather than treating raw share counts as directly comparable.
Uptime. For a defined observation period:
Uptime = Time the miner was operating ÷ Total observation time × 100
State clearly what "operating" means in a given record — powered on, hashing locally, or actively submitting shares — since these are related but distinct states, and conflating them can misrepresent the result.
Comparing local and pool-reported hashrate. A simple comparison can highlight discrepancies:
Difference from local average = (Pool-reported average − Local average) ÷ Local average × 100
This is a practical comparison for this benchmarking exercise, not a standardized mining industry metric. It is only meaningful when both figures cover comparable time windows; a 24-hour local average should not be set against a pool's 15-minute rolling estimate and reported as an epoch-level result.
Several calculations should be avoided altogether. Do not derive joules-per-terahash or any other hardware-efficiency figure from pool-reported hashrate without a matched, measured power input over the same window. Do not infer downtime solely from a temporarily low pool hashrate estimate, since dashboard smoothing and job-delivery delays can produce similar readings. Do not combine credited BTC, actual payout transactions, and a fiat conversion into a single figure without separating them, since each reflects a different stage of the settlement process.
How Payout Method Changes Interpretation
The payout method in force changes what an epoch-level benchmark can and cannot demonstrate.
Under ViaBTC's documented BTC PPS+ scheme, the block-reward component follows PPS logic and carries a 4% fee, while the transaction-fee component follows PPLNS logic and carries a separate 2% fee (ViaBTC Help Center). This means the PPS block-reward component is generally easier to reconcile with an epoch-aligned dataset, provided settlement timestamps and share/work units are aligned correctly. The transaction-fee portion of PPS+ should not be treated as fixed or fully insulated from variance, since it still depends on shares and blocks over a PPLNS-style window.
Under a standalone PPLNS scheme, ViaBTC's documentation states that rewards are calculated from a miner's share of pool hashrate over the last five difficulty rounds, applied once a found block reaches six confirmations. This PPLNS calculation window is share-based and should not be assumed to align with Bitcoin's 2,016-block difficulty epochs. A single difficulty epoch therefore remains useful for evaluating worker uptime, rejected-share activity, and connection events under PPLNS, but reward reconciliation must account for the fact that the PPLNS calculation window and the epoch boundary are not necessarily the same.
Pool Luck Is Not a Stability Metric
Pool luck describes the relationship between the blocks a pool actually finds and the number expected given its hashrate and network difficulty. It can materially affect PPLNS-based payouts within a given epoch, but it says nothing about whether a miner's connection, share submissions, or hardware performed reliably. A short observation window — including a single difficulty epoch — can show substantial luck-driven variance, particularly for smaller pools, and this variance should not be interpreted as evidence of a stability problem or a stability advantage.
A Practical Epoch Worksheet
Before the epoch begins, record the starting block height and timestamp, confirm the worker name, payout method, and mining endpoint, note the pool dashboard's hashrate averaging window if disclosed, and confirm whether variable share difficulty is active. During the epoch, collect data at a regular interval — daily readings are generally sufficient for most operations — covering local hashrate and uptime from ASIC telemetry, worker hashrate and share data from the pool dashboard, endpoint and reconnect events, and settlement entries as they post. At the next difficulty adjustment, freeze the dataset, calculate uptime from local records, compare pool-reported and local hashrate over matching windows, break down rejected shares by reason where the pool provides that detail, and reconcile credited BTC against the documented payout method.
When a variance appears, work through the likely explanations in order: local downtime or hardware faults, connection or job-delivery issues, rejected-share activity, a mismatch in dashboard measurement windows, PPLNS reward-window timing, or ordinary pool luck and transaction-fee variation. Attributing a result to the wrong layer is one of the more common errors in informal pool comparisons.
Common Measurement Errors to Avoid
A few practices recur in informal pool comparisons and should be avoided in a rigorous benchmark. Treating "accepted hashrate" as a standardized industry metric is one; the standard measurements are local hashrate, pool-reported hashrate, and valid or rejected shares, each with its own scope. Describing a pool's share target as numerically lower than the network target is another; a pool target is normally higher, which makes it easier to meet, while the corresponding share difficulty is lower than network difficulty. Presenting a single epoch's payout as proof of a pool's long-term reliability is a third, since one epoch cannot separate genuine operating consistency from short-run luck. Finally, ranking pools by fee or advertised hashrate without a shared, auditable measurement method produces comparisons that are not actually comparable.
FAQ
Why measure pool stability over a difficulty epoch instead of a calendar month?
A difficulty epoch keeps the network difficulty constant for the entire observation window, since Bitcoin only adjusts difficulty every 2,016 blocks. A calendar month can span parts of two or three difficulty periods, each with a different expected reward per unit of hashrate, which makes a month-to-month comparison less precise for isolating operating performance from network conditions.
Does a clean epoch benchmark guarantee stable future payouts?
No. An epoch benchmark documents operating consistency during one fixed network window — uptime, share handling, and settlement reconciliation. It does not remove the underlying randomness of block discovery, pool luck, or transaction-fee income, all of which can vary between epochs even when hardware and connection performance remain unchanged.
Can I compare local hashrate directly with the pool dashboard's hashrate figure?
Only if both figures cover the same averaging window. Local hashrate is typically a device-reported average over a period you control, while a pool dashboard often shows a short rolling estimate based on recent share submissions. Comparing a 24-hour local average against a 15-minute pool estimate can produce a misleading discrepancy that has nothing to do with actual performance.
How does PPLNS complicate an epoch-based benchmark?
Under ViaBTC's documented PPLNS rules, rewards are calculated from a miner's share of pool hashrate over the last five difficulty rounds, finalized once a block reaches six confirmations. This PPLNS calculation window is share-based and should not be assumed to match Bitcoin's 2,016-block difficulty epoch. As a result, operating data collected within one epoch can still be benchmarked consistently, but reward reconciliation should account for the fact that the PPLNS window and the epoch boundary may not align.
What should I do if pool-reported and local hashrate diverge significantly?
First confirm both figures use comparable time windows and that variable share difficulty, if enabled, is accounted for. If the divergence persists, review connection events, reconnects, and rejected-share data before concluding that the discrepancy reflects a genuine hardware or connectivity problem rather than a measurement mismatch.
References
- Bitcoin Developer Guide, "Block Chain" — https://developer.bitcoin.org/devguide/block_chain.html
- Bitcoin Developer Guide, "Mining" — https://developer.bitcoin.org/devguide/mining.html
- ViaBTC Help Center, "How Are Profits Calculated?" — https://support.viabtc.com/hc/en-us/articles/7207397084047-How-are-profits-calculated
- Mempool.space, REST API Documentation — https://mempool.space/docs/api/rest