Hash rate is a count of how many cryptographic hash attempts a piece of mining hardware, or the whole Bitcoin network, can perform each second, according to Minar.cc’s glossary. Difficulty adjusts because Bitcoin’s protocol recalculates, every 2,016 blocks, how hard those hash attempts need to be so that blocks keep arriving roughly every ten minutes no matter how much hashing power has joined or left the network, per the Bitcoin Wiki and Bitcoin Optech.
What hash rate is a count of
Mining hardware repeatedly runs the SHA-256 hashing function, searching for a valid block hash, according to Minar.cc’s glossary; a hash counts as valid only if it falls below a target value, per the Bitcoin Wiki. Hash rate is simply how many of those attempts happen per second. The units scale by powers of a thousand: a kilohash is 1,000 hashes per second, a megahash is 1,000,000, a gigahash is 1,000,000,000, a terahash is 10 to the 12th power, a petahash is 10 to the 15th, and an exahash is 10 to the 18th, per Minar.cc’s glossary. Minar.cc reports that a modern Bitcoin ASIC produces roughly 200–400 TH/s, citing manufacturers such as Bitmain, and that the entire Bitcoin network sits in the 600+ EH/s range as of the article’s publication date of 30 April 2026 — a figure Minar.cc says can be tracked on explorers such as mempool.space.
Hash rate is inferred, not read off a meter
Here is the part most explanations skip: nothing on the network directly counts every hash attempt made by every miner. The Bitcoin Wiki lays out the actual derivation. Difficulty is defined as a ratio between a baseline target and the current target, and because blocks are supposed to arrive one every ten minutes, the expected number of hashes needed to find a block at a given difficulty can be worked out mathematically. The Wiki gives the resulting formula as hash rate approximately equal to difficulty multiplied by 2 to the 32nd power, divided by 600 (the number of seconds in ten minutes). The Wiki’s own worked example states that at a difficulty of 22012.4941572, “at the time of writing,” the average network hash rate implied by that difficulty was around 157 gigahashes per second. That example is undated in the page text, and this page cannot establish when it was written or how it relates to the 600+ EH/s figure Minar.cc reports as of 30 April 2026. What the example demonstrates is the method, not a comparable data point: every hash rate figure quoted anywhere works the same way. It takes the current difficulty, assumes the network is producing blocks at the ten-minute target embedded in that formula, and solves for the hash rate consistent with that assumption. That is different from a live instrument reading, and it is also different from the separate calculation the protocol runs every 2,016 blocks, which does use the actual elapsed time of the previous epoch — described below.
The Wiki also gives a related calculation useful for individual miners: the expected average time to find a block equals difficulty multiplied by 2 to the 32nd power, divided by the miner’s own hash rate. Its worked example — a 1 gigahash-per-second rig at a difficulty of 20000 — comes out to just under 24 hours between blocks on average, a figure the Wiki states directly from that arithmetic.
How the difficulty retarget actually runs
Every 2,016 blocks, roughly every two weeks, Bitcoin’s protocol recalculates difficulty, according to the Bitcoin Wiki, Bitcoin Optech, and the Bitcoin Treasuries glossary. The source code that does this sits in the pow.cpp file of the Bitcoin Core repository on GitHub. At the height where a retarget is due, the code walks back to the first block of the 2,016-block window, reads its timestamp, and compares it to the timestamp of the most recent block to get the actual elapsed time for the epoch. That actual time is then compared to the target timespan for 2,016 blocks at ten minutes each, which works out to 20,160 minutes, or 14 days — a figure given directly by Simplemining.io’s explainer. If the epoch ran faster than 20,160 minutes, difficulty rises for the next epoch; if it ran slower, difficulty falls, per the same Simplemining.io walkthrough.
Simplemining.io illustrates this with hypothetical epoch lengths rather than a real historical example: if a past epoch had taken 18,000 minutes, blocks would have arrived about 11% faster than scheduled, and if it had taken 22,000 minutes, blocks would have arrived about 9% slower — in each case, Simplemining.io says, difficulty moves by roughly that same percentage in the opposite direction. These numbers describe the illustration in that article, not a specific past epoch verified elsewhere in this evidence.
The move is not unlimited. The pow.cpp code clamps the actual timespan used in the calculation: if it is shorter than one-quarter of the target timespan, the code substitutes one-quarter of the target; if it is longer than four times the target, the code substitutes four times the target. Simplemining.io describes the resulting rule as a 4x cap in either direction per epoch, which matches the bound written into the Bitcoin Core source. That means even an extreme, sudden change in hashing power cannot move difficulty by more than a factor of four in a single 2,016-block window.
Why the mechanism exists
Bitcoin Treasuries’ glossary states that the retarget exists to keep new blocks arriving at a steady average interval regardless of how much mining power joins or leaves, which in turn protects Bitcoin’s issuance schedule — the pace at which new bitcoin enters circulation. Bitcoin Optech frames the same mechanism more narrowly: difficulty adjustment algorithms govern the average time between blocks, the total block space available over time, and the rate at which the block subsidy is distributed. Minar.cc adds the security angle from the miner’s-eye view: a higher network hash rate is also read as a proxy for how expensive it would be for an attacker to control 51% of the network’s mining power and attempt to rewrite recent blocks.
Hardware efficiency compounds this. Simplemining.io illustrates, again as an arithmetic example rather than a claim about any specific miner model, that hardware rated at 15 joules per terahash produces the same hash rate as hardware rated at 21 joules per terahash while using about 29% less power. As difficulty rises and revenue per terahash compresses, that efficiency gap is what Simplemining.io says decides which operators stay profitable and which do not.
Where the rule bends: testnets
Bitcoin’s mainnet retarget rule is not the only difficulty algorithm in the Bitcoin ecosystem. Bitcoin Optech reports that Bitcoin’s testnets use a different difficulty adjustment algorithm, one designed so block production continues even after a sudden major drop in hash rate. Optech states plainly that this alternative rule cannot be used on Bitcoin’s mainnet, because it would give miners an incentive to lie about when they created their blocks — an incentive that does not exist on a testnet where the coins have no value. Optech’s own site logs two separate items on this topic: a 2024 entry describing a newly identified “time warp” vulnerability in testnet4’s difficulty adjustment algorithm, and a separate, undated entry noting discussion about resetting the testnet and adjusting its rule. The evidence held here does not establish whether these two items are connected, whether the vulnerability was ever exploited, or what specific fix, if any, was merged.
The common misreading
Readers tend to treat the hash rate figure on a dashboard the way they would treat a speedometer: a live number describing what is happening right now. It is not that. As the Bitcoin Wiki’s own formula shows, it is calculated from the current difficulty value on the assumption that the network is hitting its ten-minute target — not from a direct count of hashes performed. And difficulty itself only changes at 2,016-block intervals — it does not creep upward continuously as new miners connect, per the Bitcoin Core code and the Bitcoin Wiki. Between retargets, a surge or collapse in real mining power shows up first as blocks arriving faster or slower than ten minutes, and only later as a difficulty change.
What this page does not tell you
This page does not give a current, dated difficulty or hash rate figure for the Bitcoin network. None of the sources gathered here provide a snapshot with a specific date attached to a current difficulty value — Minar.cc’s 600+ EH/s figure, dated 30 April 2026, is the only network-wide hash rate estimate in the evidence, and it will already be stale by the time this page is read, because both hash rate and difficulty move with every retarget and every shift in mining activity.
The percentages describing an epoch running 11% fast or 9% slow, and the 29% power-saving comparison between two hardware efficiency ratings, come from Simplemining.io’s own illustrative arithmetic. They are worked examples inside that one article, not verified records of any specific historical Bitcoin epoch or any named piece of mining hardware, and this page treats them accordingly.
This page also does not evaluate difficulty adjustment algorithms used by cryptocurrencies other than Bitcoin. Bitcoin Optech notes only in general terms that alternative algorithms have sometimes produced security problems or caused systems to over- or under-pay for hash rate relative to Bitcoin, without naming which systems or dating those incidents in the material held here.
Finally, the testnet4 time warp vulnerability that Bitcoin Optech logged for 2024 is mentioned only as a headline-level entry in its own site history. Whether it has been exploited, patched, or remains open is not established by the evidence available for this page.
Sources
Every fact above is attributed to one of these reports. Where they disagree, the article says so.