Reviewed and updated: October 19, 2026.
Proof of work makes producing an acceptable block computationally costly while allowing others to check that work efficiently. Bitcoin's implementation searches for a block-header hash at or below a target. It does not ask miners to solve a useful scientific equation, and a successful hash does not replace the rest of Bitcoin's validity rules.
What miners vary and what nodes verify
The Bitcoin developer reference describes an 80-byte block header and a target encoded in its nBits field. Miners vary header inputs, including a nonce, to obtain new hash attempts. The nonce need not be a randomly chosen number each time. If a search range is exhausted, other permitted changes can produce new candidates.
The acceptance comparison is hash less than or equal to target. A smaller target permits fewer successful outcomes. Nodes also verify the header's other conditions and the block's transactions; a miner cannot make an unauthorized spend valid just by finding an exceptionally low hash.
A toy probability experiment
Use an imaginary hash with only 256 possible values, numbered 0 through 255. Set the target to 15. Values 0 through 15 qualify, so there are 16 successful outcomes. Under an independent, uniform-trial model, the chance of success per attempt is 16 / 256 = 1/16.
The expected number of attempts is 16. That does not guarantee success by the sixteenth attempt. The chance of no success in 16 attempts is (15/16)16, approximately 35.6%. This tiny model illustrates probability; Bitcoin uses a vastly larger hash space and real mining conditions differ from this classroom experiment.
If the toy target falls to 7, only eight values qualify. Success probability becomes 1/32 and the expected work doubles. This is why target and difficulty move in opposite directions, even though an individual lucky attempt can succeed immediately.
Ten minutes is an average target, not a deadline
Bitcoin mainnet adjusts difficulty at intervals of 2,016 blocks using a timestamp-based rule intended to target an average block interval of about ten minutes. Actual intervals vary. Two blocks can arrive close together, or the next block can take much longer. A fee estimate or confirmation-time display cannot promise an exact inclusion time from that average alone.
Transactions also compete for limited block space and must satisfy relay and mining policies in addition to consensus validity. Proof of work itself does not establish one fixed transactions-per-second figure for every workload.
Chain selection concerns accumulated work
Bitcoin nodes choose among valid competing chains using accumulated proof of work. Counting blocks without accounting for their work can give the wrong explanation. A reorganization replaces a previously followed branch with another valid branch that wins under the selection rules.
The Bitcoin whitepaper analyzes an attacker's chance of catching up from behind. Reversal risk depends on assumptions about relative hash power and confirmation depth. Majority hash power is important, but claiming that attacks are impossible below 51% is incorrect. Conversely, hash power does not reveal other users' signing keys.
What proof of work does not prove
| Observed fact | Remaining question |
|---|---|
| A valid block was mined | Does a particular transaction appear in it? |
| A payment has confirmations | What reversal risk is acceptable for this use? |
| A message is recorded on-chain | Was the real-world statement true? |
| A pool reports hash rate | How was it measured, over what period and with what concentration? |
Electricity, hardware, cooling and operating costs are part of mining economics. A protocol incentive does not guarantee every miner a profit. Reading PoW accurately means separating probability, validation, chain selection and business economics instead of turning one mechanism into a blanket security or profitability claim.
Sources and scope
- Bitcoin reference: block headers and inclusive hash target
- Bitcoin developer guide: difficulty and chain consensus
- Satoshi Nakamoto: Bitcoin whitepaper, particularly the attack-probability analysis
Continue reading: Bitcoin architecture and validation · Proof of stake · Bitcoin scaling limits
Editorial update: Corrected the inclusive hash target and nonce explanation; removed fixed-throughput and 51%-only attack claims; added a toy probability model and clarified accumulated-work selection.