A share counter alone cannot reproduce a mining pool’s hashrate estimate when assigned difficulty changes. You need the difficulty credited to each accepted submission, its timestamp, and the estimator’s time-window rules.
I operate BTC PoW Lab through Power CM Software. We have published an early browser-local tool, Share Work Audit, to make this arithmetic inspectable. The source and method are public. This article was prepared with AI assistance and checked against the implementation and its tests.
Start with the work, not the share count
The calculation implemented is:
TH/s = sum(accepted assigned difficulty) * 2^32
/ window_duration_seconds / 10^12
For a synthetic example, ten accepted shares with assigned difficulty 4,096 during a complete 300-second window represent about 0.5864 TH/s. Counting those shares as ten equal units would lose the information needed to compare them with shares assigned a different difficulty.
Use assigned difficulty, not the unusually high difficulty a lucky hash happened to achieve. Rejected and stale submissions do not enter the accepted-work sum.
The denominator is part of the method
Our tool implements 5-, 15- and 60-minute windows, with the interval (evaluation time - window, evaluation time]. It excludes future submissions.
Full-window mode withholds a result when the declared recording history is too short. A separate shortened-startup policy is appropriate only when you know the estimator’s actual initialization time. The first share in a file does not establish that time.
A disconnected miner’s earlier accepted work remains in the calculation until it leaves the window. The clock continues running. A capture gap, however, is missing evidence: it must not silently become a period of zero work.
A minimal input record
id,timestamp,assigned_difficulty,status
session1-1,2026-09-01T00:01:00Z,4096,accepted
session1-2,2026-09-01T00:02:00Z,8192,rejected
session1-3,2026-09-01T00:03:00Z,4096,stale
IDs must be unique across sessions. Statuses are mutually exclusive. The tool reports both submission counts and difficulty-weighted non-accepted work, because those percentages can differ. No wallet address, password or connection credentials are required.
What the output does—and does not—establish
The CSV stays in your browser. The export records the selected policy, interval, difficulty sums, denominator and estimate, plus a SHA-256 digest of the canonical parsed records. That digest identifies a particular parsed dataset; it does not prove that the original submissions occurred or that a pool accepted them.
The built-in example is synthetic and stays labeled as such. JavaScript floating-point arithmetic is used. This is an arithmetic and reproducibility aid, not payout accounting, cryptographic share validation or a completed controlled trial of BTC PoW Lab.
Clock differences, timestamp precision, smoothing and interval conventions need investigation before calling a dashboard discrepancy an error. An estimate alone also does not establish a miner’s physical hashrate or prove a payment.
Tests cover weighted work, time boundaries, disconnections, incomplete history, invalid inputs and exported provenance. Browser checks covered the actual CSV download and mobile layout. Minimal, non-sensitive counterexamples with an expected calculation are welcome in the repository.
Why we built it
The Lab continuously researches potential improvements across the mining process; experimental ideas are not demonstrated advantages. This small tool gives that work a public, reproducible starting point.
For context, the associated pool’s Hybrid Solo rules allocate 85% to the block finder, 10% to other eligible community miners and 5% to the Lab. The Lab allocation also funds rule-based bonuses, infrastructure and research. Those economics are separate from this calculator, and the tool can be used with any pool whose required records and calculation policy are available.
Top comments (0)