Short answer: “Nakamoto consensus” is a useful label for how Bitcoin combines independently enforced validity rules with proof-of-work chain selection. Nodes reject invalid blocks under the rules they run. When multiple valid branches exist, nodes select the one with the most accumulated chainwork. This creates probabilistic, not absolute, finality.
Validity First; Chain Selection Second
These are different questions. Validity asks whether a transaction or block obeys consensus rules: authorization, script execution, no overspending, permitted coinbase amount, and other block rules. Chain selection asks which valid branch a node makes active when it has more than one candidate. Hashpower cannot make a fully validating node accept an invalid block.
Candidate Blocks and Proof of Work
A miner or pool constructs a candidate block, including a previous-block hash, Merkle root, timestamp, compact target, and nonce in the header. It repeatedly hashes the header until the result satisfies the target. A valid proof is cheap for a node to verify; producing one has an expected work cost determined by the target. Mining may vary nonce and coinbase-controlled data such as an extra nonce while producing candidates.
Why “Longest Chain” Means Most Accumulated Work
The whitepaper used “longest chain,” but block count is not the modern technical comparison. Bitcoin Core records total expected work as nChainWork and adds the proof represented by each valid block header. A shorter branch can therefore have more accumulated work if its blocks represent harder targets. A node changes its active chain only to a valid candidate that wins its selection criteria.
Bitcoin whitepaper · Bitcoin Core chainwork definition
Timestamps and Mainnet Difficulty Adjustment
A block-header timestamp is miner-provided data constrained by consensus checks; it is not an authoritative wall-clock record. Median-Time-Past is derived from prior block-header times and is used by consensus rules including time-based locktime behavior. Mainnet retargets at 2,016-block boundaries. Core derives the next target from consensus header times, limits the measured timespan to one quarter through four times the target timespan, and caps the result at the proof-of-work limit. The target spacing is a long-run goal, not a promise that each block arrives in ten minutes.
Bitcoin Core proof-of-work and retarget code · BIP 113 and Median-Time-Past
Reorganizations and Probabilistic Confirmation
Two valid blocks can be found near the same time. Nodes may temporarily follow different tips until a later valid block gives one branch more accumulated work. A reorganization is a local active-chain switch to the better valid branch. Transactions from a disconnected block can be reconsidered for a node’s mempool if they remain valid and satisfy current policy. Every additional confirmation generally increases the work an alternative history must overcome, but no fixed depth creates protocol finality.
What Majority Hashpower Can—and Cannot—Do
Sustained majority hashpower can attempt to extend an alternative valid history, reverse its own recent payments under an accepting counterparty’s policy, or censor transactions while it maintains the advantage. It cannot forge another user’s signature, create coins outside the permitted subsidy and fees, or persuade a fully validating node to accept a consensus-invalid block. Cost and outcome depend on the attack duration, propagation, confirmations, hardware, energy, and participant response; a live hashrate estimate is not a universal attack-price quote.
Incentives Constrain Behavior; They Do Not Guarantee It
A valid block’s coinbase may claim the subsidy permitted at that height plus the block’s included transaction fees, subject to consensus rules. The coinbase output is spendable only after the maturity period. Those incentives can favor honest mining in the whitepaper’s model, but they do not prove that every actor has the same objective or make attacks impossible. Keep economic assumptions separate from consensus validity.
Nodes, Pools, and Individual Miners
Fully validating nodes enforce validity. Pools typically coordinate template construction and payouts. Individual miners or pool participants contribute hashrate but may not independently control a template, node, firmware, connectivity, or payout policy. Treat these as separate layers when assessing decentralization.
Start with the Plain-Language Explanation
For the accessible explanation of node roles, mining, local mempools, and what a home operator does or does not decentralize, read Bitcoin Decentralized Consensus: Nodes, Rules, and Mining.
Primary Protocol Sources
This guide relies on the Bitcoin whitepaper and the current Bitcoin Core and BIP sources linked above. Retain exact implementation statements only with a source and revision review; omit live hashrate, difficulty, pool-share, or dollar-cost figures from this evergreen reference.
Frequently Asked Questions
What is Nakamoto consensus?
Nakamoto consensus is a modern label for Bitcoin’s combination of locally enforced validity rules, proof-of-work-based chain selection, peer-to-peer propagation, and incentives. It is not a separate formal protocol rulebook.
Does Bitcoin choose the chain with the most blocks?
No. “Longest chain” is historical shorthand. Fully validating nodes select among valid candidates by accumulated chainwork, which reflects the expected work represented by the targets in their headers.
How does mainnet difficulty adjustment work?
At 2,016-block boundaries, mainnet calculates a new proof-of-work target from consensus header times and clamps the observed timespan to one quarter through four times the target timespan. Individual block intervals remain random.
Are six confirmations final?
No. Bitcoin has no universal confirmation count that creates finality. More accumulated work generally lowers reorganization risk, while an appropriate acceptance policy depends on value, counterparty, and threat model.
What can majority hashpower do?
An attacker with sustained majority hashpower can attempt valid-chain reorganizations or censorship. It cannot forge signatures, create consensus-invalid inflation, or make fully validating nodes accept invalid blocks.
Do pool miners independently control Bitcoin consensus?
A pool participant supplies work to a pool but may not choose the block template, node, payout rules, firmware, or network path. Full nodes enforce validity rules; mining work selects among valid competing histories.
