The problem: you can't directly measure someone else's hashrate
Building a mining pool dashboard, one question comes up immediately: how fast is each contributor's machine actually going? Seems simple, until you realize the pool never actually sees the raw hashing loop running — it only ever sees the occasional successful share submission. Everything in between is invisible.
So the real question becomes: can you estimate hashrate from something you can observe, without ever measuring it directly?
The insight: difficulty tells you the odds
A share is accepted when a hash meets a target difficulty — a certain number of leading zero bits. At difficulty D, the probability any single hash attempt succeeds is 1 in 2^D. That means, on average, finding one share takes 2^D attempts.
That's the whole insight. If you know how many shares someone found, and how much time passed, you can work backward to an estimate of their actual hash rate:
estimated_hashrate = (shares_found * 2^difficulty) / elapsed_seconds
No cooperation needed from the miner, no telemetry, nothing extra to build into the client. Just difficulty, share count, and a clock — all data the pool already has.
Why this is an estimate, not a measurement
Worth being honest about the real limitation here: proof-of-work is genuinely random. Finding a share in half the "expected" time isn't unusual, and neither is taking twice as long. With a small number of shares, the estimate can swing noticeably even though the underlying hardware speed hasn't changed at all.
This showed up immediately in testing — a contributor with a real, measured 4.5 MH/s (from their own miner's direct count of nonces tried) saw the dashboard estimate their hashrate at roughly a third of that, purely from a stretch of below-average luck early on. The estimate wasn't wrong — it's honestly reporting what the observed data implies — it just needs more samples to converge toward the true value. This is the same reason real, established pools show hashrate as a rolling average over a window of time rather than an instantaneous number: smoothing out exactly this kind of natural statistical noise.
What this means for choosing a difficulty setting
This estimation math also directly informs a separate, practical decision: how much easier should the pool's share-difficulty be than the real network target? Too close to the real difficulty, and shares arrive so rarely that the estimate above never has enough samples to mean anything. Too far below it, and the pool gets flooded with submissions for no real benefit.
The setting that worked well here: roughly 16 bits easier than the real network difficulty, aiming for a share every 20-30 seconds for a typical modern CPU — frequent enough for a meaningful, quickly-converging estimate, without excessive request volume.
A real, honest gap worth naming
Right now, difficulty is one fixed value applied to every connected contributor. A high-end machine and a modest laptop both get the same target — meaning the powerful machine floods the pool with shares while the modest one waits a while between each. The correct, standard fix is per-contributor variable difficulty: adjusting each miner's individual target based on their own observed submission rate, so everyone gets a similarly steady rhythm regardless of hardware. Real, valuable improvement, genuinely on the roadmap, not built yet.
Code: https://github.com/AlthaafM/Quantum-Lattice
Live dashboard: https://ql-pool.futuristicai.co.za
Top comments (0)