Short answer: Bitcoin hashrate is a rate of SHA256d hash attempts. It is useful only when the source and measurement window are clear: a device display, a pool’s credited-share estimate, and a chain-derived network estimate are different measurements. None is a price forecast, an earnings forecast, or a complete security score.
Hashrate: the Measurement and Its Units
Hashrate is conventionally written in hashes per second: H/s, kH/s, MH/s, GH/s, TH/s, PH/s, and EH/s. Each step is 1,000 times the preceding unit. A miner produces attempts; a valid block is an unusually rare attempt whose double-SHA256 header hash meets the current network target.
Target, Difficulty, and Chainwork Are Different Measurements
The target is the 256-bit threshold a valid block hash must meet. Difficulty is a relative way to describe that threshold. Chainwork is accumulated expected proof-of-work used by software to compare valid candidate chains. Difficulty is not a live count of machines, and chainwork is not a direct meter of electricity consumed.
Bitcoin Core’s block-proof and chainwork code shows how expected work is derived from a target.
How Bitcoin Core Estimates Network Hashrate
Network hashrate cannot be counted directly from the chain. Core’s getnetworkhashps estimates an average by dividing chainwork change by elapsed time over a selected set of blocks. Its default lookback is 120 blocks; the special lookback value of -1 uses blocks since the last difficulty change. Core uses the selected blocks’ timestamps, so ordinary timing variance and the selected window affect the result.
Practical rule: short windows are faster but noisier. Longer windows smooth random block timing but lag a real change. Label every network estimate with its endpoint and lookback rather than calling it a directly observed current rate.
Bitcoin Core getnetworkhashps implementation | Bitcoin Core retarget implementation
Miner-reported, Pool-effective, and Network Hashrate
Device-reported
A local rolling estimate based on the miner’s own work and settings. It is useful for operations but does not prove pool credit or payout.
Pool-effective
An estimate from credited share work over the pool’s chosen window. It depends on share target, job changes, accepted work, rejection reasons, and pool accounting.
Network estimate
A chain-derived average from accumulated work and time. It cannot identify each miner, pool, or owner.
Compare like with like: use the same period, note target or profile changes, and do not compare a few minutes of device telemetry with a much longer pool window.
What Accepted, Rejected, and Stale Shares Mean
A pool share is a proof that meets a pool-assigned target, which is generally easier than the network target. An accepted share is ordinarily an accounting event, not a confirmed Bitcoin block. A stale share commonly refers to a submission for a job replaced after a new block or job update. Other rejection reasons can include low difficulty, duplicate work, malformed data, authorization, or a pool-specific rule. Read the reason code before diagnosing hardware or networking.
Share targets can vary by channel. A raw share count is therefore not enough to calculate a rate when difficulty changes: use the pool’s credited expected work or normalized difficulty over the elapsed window.
Stratum V2 mining-target specification
Why a Short Measurement Window Misleads
Hash attempts and share discoveries are probabilistic. A short sample can look unusually high or low even when the machine is stable. A longer window reduces random variation but can hide a recent throttle, outage, power-limit change, or connection fault. Keep a timestamped log of device rate, AC wall power, pool accepted work, stale/rejected reason codes, job or target changes, and downtime.
A No-price Hashrate Measurement Workbench
Enter measurements from the same operating period. This tool converts units and shows simple rate relationships only; it does not estimate earnings, profitability, or a security level.
Enter a device rate to calculate.
Formulae: J/TH = AC watts / TH/s. Approximate share = device H/s / manual network estimate H/s. Expected blocks in a window = share x 6 target blocks/hour x hours. An expectation is not a prediction of a block, payout, or return.
How to Troubleshoot a Reported-versus-effective Gap
- Align the device and pool start/end times.
- Check accepted, stale, and rejected work separately, including the reason codes.
- Record pool target changes, job changes, restarts, curtailment, and connectivity interruptions.
- Confirm the device’s actual AC wall power and operating profile.
- Extend the sample before drawing a conclusion when the rate is low or the share interval is long.
What Hashrate Can – and Cannot – Say About Security
More honest accumulated work can increase the work needed to replace a valid history. It does not establish absolute finality, prove that all hashpower is independent, prevent every censorship attempt, or determine an attacker’s cost in currency. Confirmation depth, propagation, control of pools and templates, ownership, infrastructure, incentives, and participant response all matter.
Where Miner, Pool, Node, and Template Control Differ
Mining devices produce attempts. Pools may coordinate jobs and accounting. Fully validating nodes decide whether blocks meet their configured consensus rules. Template control is a separate question from ownership or a displayed pool rate. Stratum V2’s job-declaration design illustrates why mining communication and template-selection roles should not be collapsed into one label.
Stratum V2 Job Declaration Protocol
Related Reading
For the distinct consensus roles, read How nodes and miners enforce different parts of Bitcoin security. For the broader hardware and concentration discussion, read ASIC mining and decentralization trade-offs.
Sources
- Bitcoin Core source links above for chainwork, network-rate estimation, and retargeting.
- Bitcoin protocol documentation for validation and proof of work.
- Stratum V2 specifications for pool-target and job-declaration roles.
Frequently Asked Questions
What is Bitcoin hashrate?
Hashrate is a rate of SHA256d hash attempts, conventionally expressed in hashes per second. A device rate, a pool estimate, and a chain-derived network estimate have different sources, windows, and uncertainty.
How is network hashrate estimated?
It is inferred rather than directly counted. Bitcoin Core estimates an average from the change in accumulated chainwork divided by elapsed block time over a selected lookback window. A shorter window is noisier; a longer one responds more slowly.
Why is my pool effective hashrate different from my miner display?
A device display is a local rolling estimate. A pool estimates effective hashrate from credited share work over its own window. Share difficulty changes, stale or rejected work, outages, latency, and ordinary variance can create a difference.
What do accepted, rejected, and stale shares mean?
An accepted share met the pool-assigned target and its current accounting rules; it is usually not a block. Rejection reasons vary. A stale share commonly arrived after its job was replaced, while other rejects can be low-difficulty, duplicate, malformed, or unauthorized.
How long should I measure hashrate before troubleshooting?
Use a window that fits the rate and the question. Short windows react quickly but have more random variation, especially for low-rate miners. Record the same start and end times, target changes, outages, and rejection reasons before comparing local and pool telemetry.
Does a higher network hashrate guarantee Bitcoin security or mining profitability?
No. More honest accumulated work can raise the work needed to revise valid history, but security also depends on confirmation depth, control and coordination, incentives, and participant response. Hashrate does not guarantee a mining return or a specific security level.
