What Is Network Hashrate (and Why Every Chart Disagrees)?
What a node actually sees
Strip a node down to what it can actually witness and the mystery sharpens. It sees where the bar sits — the difficulty, which fixes what a find should cost in pulls (the previous lesson’s thermostat setting). And it sees when finds landed — the timestamps stamped into block headers. That is the complete list. No pull-counter ticks anywhere on Earth, and no miner files a report — the protocol has no field for one, and nothing could verify it if it did. (A pool can read its own members’ pulling tightly by counting the receipts they hand in — self-scoped bookkeeping, two lessons ahead; the network as a whole has no such channel.)
Even the timestamps are looser than they look. Miners set them, and consensus demands only two things: a block’s time must beat the median of the previous eleven blocks, and it may not run more than two hours ahead of a node’s clock. That is loose enough that a block’s timestamp can legally sit earlier than its parent’s. So the clock the whole estimate divides by is itself wobbling — worth one paragraph, no more, and this was it.
Somewhere right now a machine pulls a few trillion drawers. What does your node see of it?
The estimator, in one division
Difficulty prices the find: at difficulty D, one find costs on average about D × 2³² pulls. (“About”: the exact factor is 2⁴⁸ ÷ 65,535, which lands 0.0015% away — a footnote, not a derivation.) Timestamps count the finds and the elapsed seconds. Divide, and the number every chart quotes falls out:
Run it on today’s numbers from our own node (dated 2026-10-02; repainted live when the feed answers): difficulty 132,757,073,449,487, so one find costs about 5.7 × 1023 pulls. At our published last-day estimate, the network is spending ~592 s of pulling per find — within shouting distance of the 600-second schedule, as it had better be.
We publish the recipe next to the number, so nobody has to take the figure on faith. Open the raw feed and the payload’s own recipe field reads, verbatim:
The reference node software computes its estimate the same way: the chainwork difference across a window, divided by the window’s maximum minus minimum timestamps — min and max rather than first and last, precisely because the stamps need not arrive in order. Its default window is the last 120 blocks, about 20 hours. Hold that thought; it is about to matter.
Why the line wobbles
Finds are dice. The schedule says 144 a day for Bitcoin, but each find is a lottery draw, and draws cluster and gap — how a single gap can run two minutes or forty is the next lesson’s story; here only the width of the noise matters. An estimate built on N finds is noisy by roughly 1 ÷ √N, one-sigma, before a single machine changes state. A Bitcoin day holds about 144 finds: roughly ±8.3%. A week holds 1,008: about ±3%. That is the entire reason 7-day averages are the convention — and the reason our live page carries its short-window note.
A bonus only a shop running its own three nodes can show natively: faster clocks run calmer charts. Dogecoin schedules a find every minute, Litecoin every two and a half, so at the same one-day window their dice samples are bigger and their estimates tighter:
| Chain | Target spacing | Finds per day | One-day wobble, one-sigma |
|---|---|---|---|
| BTC | 600 s | 144 | ±8.3% |
| LTC | 150 s | 576 | ±4.2% |
| DOGE | 60 s | 1,440 | ±2.6% |
Fixed arithmetic, no feed required: finds per day = 86,400 ÷ target spacing, wobble ≈ 1 ÷ √N. Same math, three widths — which is why a one-day Dogecoin chart looks calmer than a one-day Bitcoin chart even on identical dice.
A chart shows the one-day estimate down 6% since yesterday. What happened to the iron?
Why every chart disagrees
Now stack the choices every chart site quietly makes. The reference node defaults to the last 120 blocks (about 20 hours — ±9.1% of pure luck) and offers a since-the-last-retarget mode; chart sites pick a day, three days, a week; some smooth with moving averages on top; and the timestamps underneath carry their legal slop. Two honest sites at the same moment are two different windows onto the same dice — of course they print different numbers. No villain, just arithmetic nobody footnotes.
The receipt: we footnote it. Every number this site publishes ships with its recipe in the same payload — the string you read above sits beside hashrate_hs in the feed, documented at /api. The next time two charts disagree, don’t ask who is lying; ask each one what its window is. One of them will tell you.
Two reputable sites show Bitcoin’s hashrate 5% apart at the same moment. Who’s wrong?
The bias we caught in our own pipeline
One more way charts diverge, and we carry the scar. Building this site’s pipeline (caught 2026-09-18), we averaged per-block rates — each block’s D × 2³² divided by its own gap — and read one chain at nearly 4× its true hashrate. The failure is pure arithmetic: a lucky 30-second gap yields an enormous per-block rate, an unlucky hour a tiny one, and the enormous ones dominate the average. The mean of per-block rates sits systematically above the honest figure — Jensen’s inequality, for those keeping receipts. Total work over total time — the ratio of sums, never the mean of ratios — is the estimator that doesn’t flatter.
That per-block series still exists in our payload, because one internal engine comparison wants it — and it ships wearing a printed warning label: “Upward-biased as absolute H/s (Jensen's inequality on 1/interval) … do not read as network hashrate. Absolute hashrate is the hashrate_hs field.” Charts don’t just pick windows; they pick formulas — and almost none of them print which.
Same headers, two formulas: total work ÷ total elapsed time, or the average of each block’s rate (D × 2³² ÷ its own gap). Which is safe to read as network hashrate?
Units, in one breath
One paragraph, as promised. Machines are quoted in TH/s, Bitcoin’s network in EH/s, and one EH/s is a million TH/s — the full ladder, plus what your own machine’s TH/s amounts to against the network, lives in the J/TH lesson and stays there. One rung further up: the estimate first crossed 1 ZH/s in 2025 — a crossing of estimates; there was no odometer to roll over. And the scrypt pair this site watches from its own nodes: Litecoin and Dogecoin each run near 2.5 PH/s — 2,505 and 2,577 TH/s (own nodes, dated 2026-10-02; repainted live) — two estimates of mostly-shared iron sitting so close they can even swap places: windows and dice, not a story. Why the same machines feed both chains is merged mining’s lesson.
Why a number nobody can count is worth estimating
Because it prices rewriting history. Every page already shelved in lesson 1’s library cost about D × 2³² pulls to stamp, so replacing yesterday’s pages means out-pulling everyone who stacked them — while they keep stacking. More hands pulling means a heavier rewrite: that is the security-budget intuition, and it is all this lesson needs of it. The live estimate’s page carries the security FAQ — /btc/hashrate — and we stop here.
FAQ
- How is network hashrate actually measured?
- It isn’t — there is no counter to read. Nodes see only two things: the current difficulty (what a find should cost in pulls — about difficulty × 2³² hashes) and when blocks actually arrived. Every hashrate figure anywhere is that expected work divided by elapsed time: an inference, never a measurement. Our own number is computed exactly this way from our own node’s headers, with the recipe published next to it in /api/chain/btc.
- Why do hashrate charts show different numbers on different sites?
- Different windows and formulas over the same dice. The reference node software defaults to the last 120 blocks (about 20 hours); chart sites use a day, three days, a week, or since the last retarget, with different averaging on top — and block timestamps are miner-set with legal slop, so even the clock wobbles. Two honest sites can disagree by several percent at the same moment without either being wrong.
- How far off can a one-day hashrate estimate be?
- Roughly ±8% for Bitcoin on luck alone — a day holds about 144 finds, and an estimate built on N finds is noisy by roughly 1/√N even when no machine switched on or off. A week of blocks tightens that to about ±3%, which is why 7-day averages are the convention. Faster chains run calmer dailies: Dogecoin’s ~1,440 finds a day put its one-day estimate near ±2.6%.
- Does a falling hashrate estimate mean miners are switching off?
- Not over a short window — a cold streak of dice looks identical to real iron leaving, and nothing in a single day’s blocks can tell you which it was. Only a sustained change separates the two, and the network’s own thermostat eventually confirms it: if hashrate truly left, the next difficulty retarget moves. For today’s live estimate and its honest wobble note, see /btc/hashrate.