Course mapModule 3 · Network Hashrate
Crypto Mining School
19 of 36 lessons live · progress saved in this browser
M1Power On5 live What Does a Bitcoin Miner Actually Do? What Is a Hash? How Do Miners Make Money? Can You Still Mine Bitcoin at Home? CPU vs GPU vs ASIC: Why Your PC Can’t Compete
M2The Iron5 live What Is an ASIC Miner? Hashrate, Watts, and J/TH: The Only Three Numbers That Matter What Is a Bitaxe? How Loud Is an ASIC Miner, Really? How Long Does a Miner Stay Profitable?
M3The Network5 live What Is Mining Difficulty? What Is Network Hashrate (and Why Every Chart Disagrees)? Why Blocks Take 2 Minutes or 40: Luck and Variance What Is a Mining Pool? What Is the Halving (and What It Does to Miners)?
M4The Money1 live What Is Hashprice? The Mining Profitability Formula (There Is Only One)soon What Power Price Kills Your Rig?soon How Long Does It Take to Mine 1 Bitcoin?soon Transaction Fees: The Half of Revenue Nobody Modelssoon
M5The Scrypt Lane3 live What Is Scrypt Mining?soon What Is Merged Mining? (AuxPoW, Plain English) How Long Does It Take to Mine 1 Litecoin? Antminer L7 vs L9 vs L11: Which Scrypt Miner Makes Sense Can You Mine Dogecoin Directly?soon
M6Home Opssoon Amps, Breakers, and 240V: Can Your Wiring Run a Miner?soon Making a Miner Livable: Noise and Heat Controlsoon Heating Your Space With a Minersoon Buying a Used ASIC Without Getting Burnedsoon Solo Mining: The Honest Lottery Mathsoon
M7Operator Gradesoon What Is Miner Capitulation?soon Hash Ribbons: Reading Hashrate Crossessoon The Puell Multiple: Miner Revenue vs Its Own Historysoon Fee Percentiles: Forecasting Revenue Like an Operatorsoon Mining Stress and Difficulty Pressure: What Our Composites Watchsoon Timing the Iron: Buying Rigs Off the Cycle Datasoon

What Is Network Hashrate (and Why Every Chart Disagrees)?

No counter exists — every figure is difficulty × 2³² worth of expected pulls divided by observed seconds. The arithmetic, the wobble, and the receipts, with live numbers from our own nodes.
loading live data…
Network hashrate is never measured. There is no odometer, and nobody can count the world’s drawer-pulls — hashrate is drawers pulled per second, worldwide, and that single line is all this page borrows from lesson 1. Every figure on every chart, ours included, is the same inference: difficulty says what one find should cost in pulls, timestamps say when the finds landed, and hashrate is expected work divided by elapsed time. See the estimator once and the wobble — and the way two honest charts disagree — stops being a mystery and becomes arithmetic you can redo yourself before the end of this page.
Two honest numbers · same node, same minute · static figures dated 2026-10-02, repainted live
From difficulty alone
950.3 EH/s
difficulty × 2³² ÷ 600 s — assumes on-schedule blocks; computed in this page · fallback 2026-10-02
From observed pace
963.7 EH/s
total work ÷ elapsed seconds, last day — estimated from our own node’s headers · fallback 2026-10-02
+8.4%the published estimate’s 7-day move — part iron, part dice; it says nothing by itself · fallback 2026-10-02
Same node, same minute, both honest, neither a count. The left number assumes blocks landed exactly on the 600-second schedule; the right divides the work the last day’s headers prove by the seconds they actually took. The space between them is observed pace plus dice — which is this whole lesson. The live number’s full dashboard is /btc/hashrate; this page explains why that dashboard carries a wobble note.

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:

difficulty where the bar sits timestamps when the finds landed price of one find ≈ D × 2³² pulls finds ÷ seconds counted between stamps estimated pulls per second
The complete pipeline behind every hashrate chart in existence. Nothing in it counts pulls: the left box prices a find, the right box times the finds, and the division at the bottom is all anyone has ever had. Charts differ in the window they time over — and occasionally in the arithmetic itself.

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:

total work (sum of difficulty x 2^32 per block) over the last day / elapsed seconds, from our own node's headers

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.

Pick a window · pure arithmetic, nothing fetched
144 blocks · one day
An estimate built on 144 blocks (one day) is noisy by roughly ±8.3% one-sigma on luck alone — before a single machine switches on or off.

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:

ChainTarget spacingFinds per dayOne-day wobble, one-sigma
BTC600 s144±8.3%
LTC150 s576±4.2%
DOGE60 s1,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.
Do it now. Reproduce the world’s most-quoted mining number yourself, right now, with one division: open /btc/difficulty and copy the live difficulty; multiply it by 4,294,967,296 (2³² — the average pulls one find costs at difficulty 1) and divide by 600 (the schedule); then compare your answer with the live tile on /btc/hashrate. You will land within a few percent — and the leftover is observed pace plus dice, which you now understand. For the receipt, open the raw feed and find the recipe string printed next to hashrate_hs. You didn’t look up the network’s hashrate; you inferred it — the only thing anyone has ever done.
Completes automatically when you continue below — saved in this browser only, no account, no tracking.
Next lesson → Module 3 · The Network
Why Blocks Take 2 Minutes or 40: Luck and Variance
Block discovery is dice. “The network is slow today” usually isn’t.
Source: difficulty, block pace and the last-day hashrate estimates live from BasinTwo’s own Bitcoin, Litecoin and Dogecoin full nodes via the free /api/chain feeds (static fallbacks dated 2026-10-02), with the estimator recipe published verbatim inside each payload. Noise widths are standard 1/√N arithmetic — redo them by hand. Timestamp rules and the 120-block default are from the reference node implementation’s published source, checked 2026-10-02. The 4× bias is our own build log, 2026-09-18, and its warning label ships in the API today. Not financial advice.