Bitcoin proof of work makes proposing blocks costly and gives nodes an objective way to compare competing valid histories. Miners search for a double SHA-256 hash of an 80-byte block header that is at or below the current target. Full nodes independently enforce Bitcoin’s transaction and block rules, then follow the valid chain with the most accumulated chainwork. Confirmations therefore make reversal progressively less likely, not impossible.
This guide explains the protocol without turning changing hashrate or difficulty snapshots into permanent facts. It also separates full-node validation, block-template construction, pool coordination, and ASIC hashing—jobs that are often compressed into the single word “mining.”
What Is Bitcoin Proof of Work?
Proof of work is the mechanism Bitcoin uses to attach measurable expected computational work to a candidate block header. A valid header hash is difficult to find but quick for any node to verify. The original Bitcoin whitepaper describes this asymmetry as the basis for ordering transactions without a central timestamping authority.
Proof of work is only one part of consensus. A header that meets the target does not make arbitrary transactions valid. Each node still checks the block against its own configured consensus rules. The Bitcoin block-chain guide describes how independently validating nodes maintain their accepted chain.
Miners, Full Nodes, Pools, and Wallets Have Different Jobs
| Participant | Protocol role |
|---|---|
| Wallet or user | Creates and signs transactions, then sends them to one or more peers. |
| Full node | Validates transactions and blocks, maintains chain state, and selects the valid most-work branch it knows. |
| Mining node or template builder | Selects transactions, constructs a coinbase transaction, and builds a candidate block. |
| Pool or coordinator | Distributes jobs and accounts for contributed shares; depending on the setup, it may control the candidate template. |
| ASIC hash worker | Tests header candidates and returns results. An ASIC is not a full node. |
Full nodes enforce validity
A full node verifies applicable scripts, transaction value rules, block structure, proof of work, the permitted coinbase amount, and other consensus conditions. It does not accept an invalid block merely because substantial hashpower produced it. Running a miner without a separately controlled validating node does not independently verify the ledger.
Mining software and ASICs search candidate headers
Solo mining software can request a template from a local node. A pool commonly supplies jobs to connected hash workers and pays them according to its accounting rules. The Bitcoin mining guide shows why an ASIC, a pool share, a block template, and a network-valid block are not interchangeable.
How a Candidate Block Becomes a Valid Block
- A template builder selects valid transactions and creates a coinbase transaction.
- The transaction identifiers are committed through a Merkle root in the block header.
- Mining software varies the nonce and can alter the coinbase extra nonce, Merkle root, timestamp, version, or transaction set to create more candidates.
- ASICs repeatedly hash serialized headers.
- When a hash meets the network target, the complete block is broadcast.
- Each receiving full node independently validates the header, every transaction, and all other consensus conditions before accepting it.
The 80-byte header and double SHA-256
The serialized header contains version, previous-block hash, Merkle root, timestamp, compact target, and a four-byte nonce. Bitcoin hashes that header twice with SHA-256. The result must be numerically less than or equal to the target. The block-header reference documents the fields and target encoding.
The nonce alone is far too small for modern mining workloads. Changing the coinbase extra nonce changes the transaction identifier and Merkle root, providing new header search space. “Puzzle” is a useful shorthand, but there is no known shortcut that materially outperforms testing candidate headers.
A valid proof does not bypass block validation
After a miner broadcasts a candidate, nodes check proof of work and the committed block data. A block can have a qualifying header hash and still be rejected for an invalid transaction, excessive coinbase output, bad Merkle commitment, incorrect time, or another consensus violation. Bitcoin Core’s validation implementation is the executable reference for those checks.
Target, Difficulty, and Chainwork
The target is the 256-bit threshold a block-header hash must meet. The header stores a compact representation called nBits. Difficulty is a relative presentation of how restrictive that target is compared with the reference target. At conventional difficulty D, expected hashes are approximately difficulty multiplied by 2^32.
Each accepted header adds a calculated amount of chainwork derived from its target. It does not record the miner’s actual number of attempts or electricity meter. Bitcoin Core’s chainwork calculation derives expected work from the encoded target.
The 2,016-block difficulty adjustment
Mainnet retargets every 2,016 blocks toward a 600-second average interval. Bitcoin Core compares the selected period’s timestamps with the two-week target and bounds the adjustment so the target cannot become more than four times easier or harder in one retarget. The commit-pinned proof-of-work implementation shows the calculation.
Ten minutes is an average, not a schedule
Block discovery is random. Two blocks may arrive seconds apart, or the network may wait much longer than ten minutes. A sudden hashrate change affects observed intervals until difficulty adjusts, and even a stable hashrate produces variable intervals. Hashrate displayed by an explorer is an estimate over a chosen window; difficulty is a chain parameter. Bitcoin Core exposes both difficulty and cumulative chainwork through getblockchaininfo.
Competing Tips, Stale Blocks, and Reorganizations
Two miners can find valid blocks referencing the same parent at nearly the same time. Nodes may temporarily accept different tips based on which valid block they received first. When one branch accumulates more chainwork, nodes reorganize to the valid most-work branch. The other valid block becomes stale.
A transaction from the stale branch may already appear in the winning branch, may return to a node’s mempool if it remains valid and non-conflicting, or may be excluded. A stale coinbase reward never matures. These ordinary short forks are why a recent confirmation is strong evidence rather than absolute finality.
Confirmations Provide Probabilistic Finality
A transaction has one confirmation when it is included in a block on the node’s current best chain. Each subsequent block normally adds more chainwork behind it. Reversing the transaction then requires a competing valid branch to overtake the current branch. The probability depends on attacker hashrate, confirmation depth, propagation, timing, and the specific strategy.
Why six confirmations are not a protocol guarantee
Six confirmations are a policy convention, not a finality opcode or consensus rule. They also do not promise exactly one hour because block intervals vary. A recipient should choose a threshold based on value, reversibility, counterparty risk, and its threat model. The payment-processing guide frames confirmation depth as risk management rather than mathematical irreversibility.
What a Majority-Hash Attacker Can and Cannot Do
“51% attack” is shorthand for attacks involving a large share of active work. An attacker below half can attempt a short reorganization with non-zero success probability. Sustained majority work makes continued branch dominance more likely, but does not make every attack free, hidden, or certain.
Capabilities while control persists
- Attempt to replace the attacker’s own recent payment with a conflicting spend.
- Exclude selected transactions from blocks the attacker produces.
- Build a private valid branch and publish it in an attempt to orphan competing blocks.
Feasibility depends on available hardware, energy, opportunity cost, duration, propagation, confirmation depth, and how other participants respond. A single live hashrate estimate cannot establish a permanent currency cost.
Limits imposed by full-node validation
Hashpower cannot forge signatures, spend coins without valid authorization, create arbitrary subsidy, or force independently validating nodes to accept a block that violates their consensus rules. It also cannot guarantee permanent censorship after control ends; an honest miner may later include a still-valid transaction.
Block Subsidy, Fees, and Issuance
From heights 840,000 through 1,049,999, the maximum block subsidy is 3.125 BTC. At height 1,050,000 it becomes 1.5625 BTC. Calendar dates are estimates because block intervals are random. The block reward is the subsidy plus eligible transaction fees, so it varies by block and a miner may claim less than the permitted maximum.
Full nodes enforce the permitted coinbase amount; proof of work does not independently enforce the supply schedule. Bitcoin Core’s mainnet parameters set the 210,000-block halving interval, while validation code rejects an excessive coinbase. A coinbase output also must mature for 100 blocks before it can be spent.
Long-run miner revenue is an economic outcome
The subsidy eventually reaches zero, not necessarily the total block reward. Included transaction fees can continue to compensate miners. Future fee revenue is not guaranteed: fee demand, block-space use, hashrate, efficiency, miner participation, and attack resources will determine the resulting security budget.
Energy Use: What Proof of Work Does and Does Not Prove
Mining consumes electricity while searching for qualifying headers, but the blockchain does not store electricity. Accepted headers provide evidence of expected work based on their targets. Security economics depend on the cost and availability of competing work, distribution of control, validation, connectivity, and participant response—not joules alone.
Global mining electricity use is modeled rather than read from a network power meter. The Cambridge methodology publishes lower, best-guess, and upper estimates based on hashrate, hardware efficiency, profitability, and facility assumptions. Claims about a renewable share, stranded energy, or emissions require a dated methodology and a defined boundary.
Mining can act as a controllable load in some installations, but interconnection, automation, market rules, and contracts determine whether curtailment benefits a grid. The U.S. Energy Information Administration analysis documents both demand-response participation and potential effects on electricity cost, reliability, and emissions.
Heat recovery has a boundary and a counterfactual
Nearly all electrical input to an indoor miner ultimately becomes heat within the room or duct boundary. That is approximately equivalent to resistance heating, not free energy, and a heat pump can deliver more useful heat per kilowatt-hour. Credit only heat that displaces a real heating load when and where it is needed. Use D-Central’s space-heater guide and power-cost calculator to model the site rather than assume universal savings.
Home Mining Without Conflating a Miner With a Node
A compact miner can teach proof of work and contribute a small probability of block discovery. It does not independently validate the chain merely because it hashes. Direct node-backed solo mining requires a full node, template-building software, an ASIC, and reliable network connectivity. A solo-pool service can provide a high-variance payout model while still coordinating jobs or templates.
Explore the Bitaxe hub or open-source miner catalog for small-scale hardware. For full-size equipment, include electrical capacity, heat, noise, ventilation, uptime, pool terms, and repairs in the operating plan; D-Central provides ASIC repair and mining hosting information.
Independent participation is multidimensional. Ownership of hardware can broaden participation, while meaningful control also depends on the node, pool, template policy, firmware, connectivity, and hosting. D-Central’s mining training and consulting can help map those boundaries before equipment is deployed.
Frequently Asked Questions
What exactly is Bitcoin proof of work?
It is the process of searching for a double SHA-256 block-header hash at or below the target. The proof lets nodes compare valid competing histories by accumulated chainwork, while each full node still enforces every applicable consensus rule.
What is the difference between a Bitcoin miner and a full node?
An ASIC tests header candidates. Mining software or a pool builds jobs and templates. A full node validates transactions and blocks and selects the valid most-work chain. One operator may run several roles, but the roles are not interchangeable.
What is the current Bitcoin block subsidy?
The maximum subsidy is 3.125 BTC from heights 840,000 through 1,049,999. At height 1,050,000 it becomes 1.5625 BTC. A block may also claim eligible transaction fees, so total block reward varies.
How does Bitcoin difficulty adjust?
Mainnet retargets every 2,016 blocks toward a 600-second average interval and bounds the target change to a factor of four in either direction. Individual block intervals remain random, and hashrate estimates depend on the measurement window.
Is a Bitcoin transaction final after six confirmations?
No fixed count creates absolute finality. Six confirmations are a common policy threshold. Reversal risk normally declines as chainwork accumulates, but the required depth should reflect value, reversibility, and the assumed attacker.
What can a 51% attacker do?
Sustained majority work can make some reorganizations, double-spends of the attacker’s own payments, and censorship attempts more reliable. It cannot forge signatures, spend other users’ coins, create arbitrary subsidy, or make honest full nodes accept invalid blocks.
Does Bitcoin store the energy used for mining?
No. Accepted headers provide evidence of expected computational work derived from the target. The chain does not measure or store joules, and attack economics depend on hardware, electricity, time, coordination, and response.
Does a Bitaxe or home ASIC run a Bitcoin full node?
Not by itself. A compact ASIC performs hashing and connects to mining software or a pool. Independent node-backed solo mining requires a separately controlled full node and template path in addition to the hash worker.
