Hashrate is a rate of attempted double-SHA-256 work, not a counter of valid blocks and not a directly observable property of the whole network. A miner can measure its own device or pool-side rate from submitted work, while network hashrate is inferred statistically from recent block production and proof-of-work difficulty. Because block discovery is probabilistic, every short-window hashrate estimate contains luck and timing noise.
One H/s means one candidate proof-of-work hash attempt per second. Bitcoin miners repeatedly hash an 80-byte block header with double SHA-256 and vary nonce, extranonce-derived Merkle root, version or time fields to explore a huge search space. A higher hashrate means more independent trials per unit time, not that any individual trial is more likely to succeed.
An ASIC's hashrate is measured locally from completed work; a pool estimates a worker's effective hashrate from accepted shares over a window. Network hashrate is different again: no global meter reports every miner. It is inferred from how much proof of work the network appears to produce over time. These three numbers answer different questions and need not match over short intervals.
Bitcoin Core's getnetworkhashps returns an estimated hashes-per-second value from recent blocks. The implementation compares accumulated work over a chosen block window with elapsed block timestamps; the default RPC window is 120 blocks, while -1 uses blocks since the last difficulty change. Short windows react faster but are noisier; long windows are smoother but lag real changes.
The target is the maximum permitted proof-of-work hash value for a block. Difficulty is a relative way to express how hard that target is compared with the reference difficulty. Lower target means more expected trials. Hashrate describes how quickly trials are attempted; difficulty describes how much expected work a valid block requires. Neither number is a substitute for the other.
On mainnet the proof-of-work target is retargeted every 2,016 blocks toward a two-week interval, subject to the protocol's adjustment bounds. If hashrate rises suddenly, blocks tend to arrive faster until the next adjustment raises difficulty; if hashrate falls, blocks tend to arrive slower until difficulty can adjust downward. The protocol therefore responds to hashrate indirectly through observed block timing, not by measuring miners.
At fixed difficulty, expected block frequency scales approximately with hashrate, but actual discoveries remain random. A miner with 1% of total hashrate has roughly 1% of the probability of finding the next block, not a guaranteed one-block-per-hundred schedule. This statistical variance is why pools exist and why short-term network-hashrate charts can jump even when physical mining capacity barely changed.
Current hashrate and historical chainwork are related but not identical. Chainwork accumulates the expected work represented by every block in a branch; hashrate is a rate at a point or over a window. Confirmations gain security because replacing them requires competing accumulated work. A temporary hashrate spike today does not retroactively change the chainwork already embedded in older blocks.
More hashrate gives miners greater probability of extending or privately competing with the chain. Majority hashrate can make censorship and deep reorganization attacks much more reliable, but it still cannot make a block that violates the victim node's consensus rules valid. Hashpower influences which valid history wins; full nodes define validity under the rules they run.
Hashrate alone does not reveal electricity use. Power depends on hardware efficiency in joules per terahash, voltage/frequency settings, cooling and auxiliary loads. Two fleets can deliver the same EH/s with very different megawatt demand. Converting hashrate into energy therefore requires an efficiency assumption or measured fleet data, not a protocol identity.
For a local miner, compare ASIC-reported hashrate with pool accepted-share hashrate over a sufficiently long window and inspect rejects. For the network, query getnetworkhashps with multiple windows, compare difficulty and block intervals, and state the estimation window. Any precise network hashrate number without a time window and uncertainty boundary should be treated as an estimate, not an exact census.
For the clearest picture, read this entry together with Mining, ASIC Miner, Difficulty adjustment, Proof of Work, Hashprice, Bitcoin. The reverse links also lead from ASIC Miner, Mining Pool, Solo Mining, Demand Response Mining.