Hashrate measures computational attempts per second under a particular algorithm, not coins produced per hour. Compare matching algorithms and units, then distinguish a specification from accepted work over a complete period. Revenue needs additional assumptions about rewards, network conditions and the pool’s payment rules.
The simplified calculation assumes constant running rate. Do not deduct downtime twice from an average already including it.
BTKWIN.COM · EDUCATIONAL EXAMPLECheck one: units and algorithm
One TH/s means one trillion hash attempts per second. One PH/s equals one thousand TH/s, and one EH/s equals one thousand PH/s. A hypothetical 200 TH/s equals 0.2 PH/s. Reading only the numerical value can reverse a comparison when prefixes differ.
Also identify the network, algorithm, hardware model and operating mode. Hash attempts under different algorithms are not interchangeable units of economic output. A larger numerical rate on another algorithm does not by itself indicate greater revenue or better equipment for the intended task.
Distinguish rate from accumulated work. A device holding 200 TH/s for one hour performs nominal work of 200 × 3,600 = 720,000 TH. The final unit is terahashes, not terahashes per second. This counts attempts under the assumptions; it does not determine blocks or coins.
Check two: local readings and pool-accepted work
A device can report a local rate while a pool estimates contribution from submitted and accepted shares over a window. The Bitcoin mining developer guide explains shares and the distinction between the pool’s target and the network block target. An accepted share is not necessarily a new block.
If workers submit shares at different difficulty levels, raw message counts need not represent equal expected work. Use the pool’s documented weighted-work or estimated-rate measure rather than assuming twice the share count always means twice the underlying rate.
The Braiins explanation of shares and estimated hashrate discusses probabilistic variation and the observation window. A lower five-minute pool reading alone is insufficient to diagnose a hardware fault. Align periods and inspect rejection and connectivity records.
Account for downtime across the whole observation
Assume a hypothetical machine runs at 200 TH/s for twenty-one of twenty-four hours and is stopped for three. Its complete-day average before rejected work is 200 × 21 ÷ 24 = 175 TH/s. A screen captured during running can show two hundred without describing the day’s total work.
Now assume 2% of submitted work, measured consistently and weighted as required, is not accepted. The simplified accepted full-day average is 175 × 0.98 = 171.5 TH/s. This is not a formula for subtracting an unweighted rejected-share count when share difficulties differ.
| Hypothetical measure | Value |
|---|---|
| Rate while operating | 200 TH/s |
| Operating time | 21 of 24 hours |
| Day average before rejection | 175 TH/s |
| Accepted day average under the assumption | 171.5 TH/s |
If a pool’s existing daily average already includes stopped hours, do not reduce it by uptime again. Record start and end, active device count, restarts and mode changes. For several devices, combine averages over matching periods rather than adding each machine’s best instantaneous reading from unrelated times.
Check three: computational capacity is not a fixed reward
Finding a block is probabilistic. More attempts raise expected opportunity when other conditions remain constant, but do not allocate a fixed number of coins to every machine each hour. Solo and pooled arrangements distribute variability differently, and a scheduled pool payout does not mean the individual device found a block at that moment.
A relative model can use an assumed network share, expected block count and reward, but those inputs remain conditional. Network hashrate itself is generally estimated through a method and observation window rather than directly counting every machine in real time. Keep the measurement scope visible.
Read the current pool’s rules for recognized work, transaction fees, payout variability, service fees and thresholds. Earned balance, eligibility for payout and a transfer received in a wallet are separate stages. A delayed receipt can therefore require checking payment conditions rather than assuming the hardware rate changed.
Calculate illustrative revenue from a stated unit yield
Assume solely for education a gross yield of 0.0000003 BTC per TH/s per day. At accepted average two hundred TH/s, the model gives 0.00006 BTC per day. At 171.5 TH/s, it gives 0.00005145 BTC. These are outputs of an invented yield input, not current mining-income quotations.
Save that input’s unit, timestamp and what it includes. A yield per PH/s combined with a TH/s rate without conversion introduces a thousandfold error. If the input already includes pool fees, do not deduct them again; if gross, apply documented costs separately.
Keep earned bitcoin and its cash valuation in separate columns. Cash revenue can change with BTC price even when the quantity is unchanged. Extending one day’s yield over a month is a fixed-input scenario, not an observation of future earnings.
Check four: place the rate beside energy and all relevant costs
Assume running power of three kilowatts for twenty-one hours. Energy is sixty-three kWh before external supporting equipment. At an invented tariff of 0.1 monetary units per kWh, the associated energy charge is 6.3. That measures one cost component rather than the net result of a mining project.
Add applicable ventilation, cooling, maintenance, service, equipment and installation costs under a stated accounting scope. A higher-rate device can consume more power, so rate alone does not describe efficiency. Reduced operating hours can lower both energy and work; do not change one side of a scenario while leaving the other implicitly continuous.
After restarting, a displayed last-hour average can still contain stopped time. Five minutes of operation divided over a full hour differs from an average restricted to those five minutes. Identify the time denominator before calling the difference reduced device performance.
Use persistent evidence before diagnosing a problem
Investigate a sustained deviation over matched periods alongside rejection, repeated disconnects, power and temperature records. Those observations can justify further checking without identifying a failed component on their own. Use manufacturer guidance rather than changing power settings or electrical arrangements based on one rate snapshot.
Keep model, algorithm, mode, local rate, accepted average, period, energy and connectivity together. The watchlist can track the revenue asset while the wallet helper addresses destination custody separately. The useful result is a defined work measurement followed by a conditional revenue estimate and explicit costs, not a promise of fixed coin output.
Continue reading
English content and examples reviewed: 27 October 2026. Read the Arabic edition.