FROM SHARES TO AN ESTIMATE

Can you reproduce
the hashrate?

Bring a share record. Recalculate the accepted work over 5, 15 and 60 minutes, with the assumptions visible.

1. Bring the evidence

One row per submission, with its pool-assigned difficulty and final status. Use unique IDs across reconnects. Include rejected and stale submissions as separate, mutually exclusive statuses. Do not use a lucky hash's achieved difficulty or the miner's best share.

Open CSV (up to 10 MB) Or paste the record

Format: id,timestamp,assigned_difficulty,status. Plain comma-separated values; UTC dates ending in Z. Up to 50,000 rows. No wallet, password or connection details needed.

2. Set the observation

Declare the interval you actually recorded. A silence counts as zero work only if the capture was functioning. Capture gaps cannot be treated as miner downtime.

Recording starts (UTC)Recording ends (UTC)Evaluate at (UTC)

Denominator policy

Shortened startup is valid only when recording starts at the estimator's actual initialization. The first captured share does not establish that time. Disconnections never stop the clock.

I confirm continuous capture over the stated interval, including any periods without submissions.

3. Inspect the result

Window	TH/s estimate	Accepted difficulty	Seconds	Non-accepted count	Non-accepted work

Rejected and stale work is excluded from hashrate. Non-accepted rates include both statuses; counts and difficulty-weighted work can tell different stories.

The method is the point.

TH/s = Σ accepted assigned difficulty × 2³² ÷ seconds ÷ 10¹²

Each window includes submissions after its left boundary and at or before the evaluation time: (t − window, t]. All selected rows are summed; we apply no smoothing and do not remove work at disconnect. Compare these conventions, clock alignment and timestamp precision with the dashboard before interpreting a difference.