DEV Community: BTC PoW Lab

Reproducing a mining dashboard’s hashrate from share records

BTC PoW Lab — Sat, 05 Sep 2026 22:44:53 +0000

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.

A Mining-Pool Payout Promise Is Not an Accounting System

BTC PoW Lab — Thu, 03 Sep 2026 18:29:00 +0000

Disclosure: I operate BTC PoW Lab Pool, which is used below as a case study. This draft was prepared with AI assistance and reviewed against the live public API and project records. The pool has not found a block and has no payout history.

A percentage on a mining-pool landing page is not an accounting system.

“The finder receives 85%” sounds precise. It is not enough to answer the questions that appear after a real block:

Which miners were eligible at the exact block height?
Which accepted shares were inside the reward window?
Was the finder excluded from the community allocation?
How were rounding and dust handled?
Which exchange rate produced the USD estimate shown in a screenshot?
Can the operator reproduce the result after a restart or database restore?

If those answers are calculated from mutable live state, two honest queries made seconds apart can disagree. A restart can make the disagreement harder to explain. A screenshot can then look like stronger evidence than the database.

The fix is to treat the block as an accounting event and create an immutable snapshot.

Separate the economic identity from the connection

A miner may use several workers, reconnect repeatedly, or run more than one device. Those are operational sessions, not necessarily separate economic participants.

The payout identity should be the Bitcoin address or another explicit settlement identifier. Workers and sessions roll up into that identity. This prevents a participant from manufacturing additional reward weight by splitting one hashrate source into many worker names.

The raw events should still preserve:

session ID;
worker ID;
payout identity;
accepted difficulty;
block height;
server timestamp;
job and extranonce identifiers;
rejection reason, when applicable.

Aggregation should change the accounting view, not erase the evidence.

Freeze rules and inputs together

At block detection, the snapshot should capture more than the final totals. It should include the inputs needed to reproduce them:

{
  "block_height": 965350,
  "rules_version": "hybrid-solo-tiered-community-7d-v5",
  "eligibility_window_seconds": 604800,
  "finder_identity": "bc1q...",
  "finder_excluded": true,
  "network_reward_sats": 0,
  "allocations": [],
  "created_at": "2026-09-03T00:00:00Z",
  "input_digest": "sha256:..."
}

rules_version matters because software changes. Re-running today’s code against last month’s data is not necessarily a valid historical reconstruction.

An input_digest matters because it binds the snapshot to the accepted-work set used by the calculation. If a later audit imports events from backup, the digest can establish whether it reconstructed the same input.

Account in satoshis, display in fiat

Settlement amounts should be integers in satoshis. Fiat values are presentation-layer estimates.

A user may capture “US$ 120.20” and see “US$ 117.80” later even when the underlying reward remains exactly 158,323 sats. That is normal if the BTC/USD quote changed. The interface should show both values and explain which one is authoritative.

For every allocation, persist:

exact total_sats;
allocation components;
remainder policy;
dust state;
fiat quote and quote timestamp used for display;
status such as PROJECTED, FROZEN, PAYABLE, DEFERRED_DUST, BROADCAST, or CONFIRMED.

Never overwrite the satoshi amount merely because the display quote changed.

Make rounding deterministic

If proportional weights do not divide the reward exactly, the system needs a published remainder rule. Examples include largest remainder or deterministic assignment ordered by a stable identity hash.

The important part is not which reasonable rule is selected. The important part is that the rule is versioned, deterministic, and applied before the snapshot is sealed.

The sum must satisfy an invariant:

finder_sats + community_sats + lab_sats + explicit_remainders
  = distributable_block_reward_sats

If the invariant fails, payout preparation must fail closed.

Calculation and signing are different trust boundaries

An automatic calculator does not need access to private keys. A signer does.

That difference is operationally important. A safer pipeline is:

detect a candidate block;
verify it against the Bitcoin node;
freeze the accounting snapshot;
wait for the configured confirmation threshold;
construct a batch transaction or PSBT from the frozen plan;
validate outputs against the snapshot;
sign in a separate, constrained environment;
broadcast and record the transaction ID;
reconcile every output and fee.

This is also where “automatic payouts” can become custody. If community funds first arrive at an operator-controlled address, the operator controls those funds until the distribution transaction is signed. Automation reduces manual work; it does not remove the custody boundary.

Design the appeal process before the dispute

Suppose a miner says, “I should have received more,” and sends a screenshot.

The operator should be able to produce an audit bundle without editing the production database:

block and confirmation evidence;
rules version;
participant identity and eligibility interval;
accepted-work rows or a verifiable aggregate;
weight calculation;
exact satoshi allocation;
fiat quote metadata;
snapshot digest;
payout transaction and reconciliation state.

The screenshot is then useful context, not the sole source of truth. It may reveal a stale UI, a changed exchange rate, a different worker aggregation, or a real accounting defect.

Survive restarts and machine loss

The snapshot and event journal should not live only on the machine running Stratum.

A practical minimum is:

an atomic local snapshot;
an encrypted off-site copy;
a manifest containing hashes and schema versions;
a restore test on a separate path;
documented recovery-point and recovery-time objectives.

“Backup completed” is weaker than “backup downloaded, decrypted, hashed, and restored successfully.” Verification is part of the backup.

What transparency can and cannot prove

Before its first block, a pool can prove that its rules are published, its telemetry exists, its snapshot code is deterministic, and its backups restore.

It cannot prove a successful payout history that does not exist.

That distinction is healthy. Engineering evidence should make future claims testable without turning preparation into a claim of completed performance.

The BTC PoW Lab Pool accounting model and live limitations are public here:

The broader lesson applies beyond mining: if money is distributed from changing state, freeze the rules, freeze the inputs, record exact units, and separate calculation from signing.