The Bitcoin blockchain is often described as a permanent ledger.
That description is useful only when its limits are understood. Bitcoin does not rely on one central ledger keeper, one database server, or one miner announcing the official history. Nodes receive blocks from peers, validate them independently, track competing valid branches, and select the valid chain with the greatest accumulated proof of work under their rules.
The result is a shared history that converges through validation, proof of work, and network propagation.
The blockchain is an ordered block history
Each Bitcoin block header contains the hash of a previous block.
That reference links a new block to a specific parent. The parent links to its parent, continuing backward to the genesis block.
A block's own hash commits to its header, including the previous-block reference and the Merkle root for its transaction identifiers. Changing an earlier block changes its hash. The later block that referenced the old hash would no longer point to the altered version.
An attacker attempting to replace earlier history must therefore construct a competing valid branch from the changed point and supply enough proof of work for nodes to select it over the current valid chain.
The linkage makes history tamper-evident. Proof of work and independent validation determine which linked history is selected.
Every node maintains its own view
There is no database process that pushes one authoritative blockchain state to every participant.
Each full node maintains local data such as:
- A block index describing known headers and block relationships.
- Chainwork values for known blocks.
- One or more chainstate views.
- A selected active chain.
- Raw block and undo data according to storage configuration.
- Peer and validation state.
- Optional indexes for additional queries.
Nodes can learn about blocks at different times. One node may know a competing branch that another has not seen. Their selected tips can briefly differ.
Convergence happens as valid blocks propagate and one valid branch accumulates more proof of work. A node does not need identical storage or mempool contents to enforce compatible consensus rules.
Validation comes before activation
A block's proof of work is not enough by itself.
A node checks the header and block under the applicable consensus rules. It verifies transaction validity, UTXO spends, scripts, block limits, coinbase rules, commitments, and chain context.
A node only activates a candidate chain after validating the required blocks. Among valid candidate chains, accumulated proof of work guides chain selection under that node's rules.
This prevents miners from buying permission to create invalid outputs, bypass signatures, exceed allowed issuance, or redefine block validity. More proof of work can win a competition between valid histories. It cannot make an invalid history valid to a node that enforces the rules.
Accumulated work is not simply block count
A common shortcut says Bitcoin follows the longest chain.
The more precise rule is based on accumulated proof of work, often called chainwork.
Bitcoin Core derives the work associated with a block from its encoded proof-of-work target. A block at a harder target represents more expected hashing work than a block at an easier target. Chainwork is the sum of the work values along a branch.
Two branches with the same number of blocks can therefore have different accumulated work.
On mainnet, difficulty normally remains constant within an adjustment period, so block count and chainwork often move together over short comparisons. The protocol still compares work, not height alone.
"Most-work valid chain" is a better description than "longest chain."
New blocks extend a chosen parent
A miner or pool selects a previous block to extend and builds a candidate on top of it.
Most miners usually work near the tip they believe nodes will accept because extending an older or weaker branch reduces the chance that their block will remain in the selected history.
Network delay can still produce competing valid blocks. Two miners can extend the same parent almost simultaneously. Some nodes see one block first; others see the other.
At that moment, both branches can be valid and have equal accumulated work. A node can temporarily remain on the first valid tip it received while tracking the competitor.
The next valid block found on one branch normally breaks the tie by adding more work. Nodes that had selected the other branch can then reorganize.
A reorganization changes the selected chain
A chain reorganization occurs when a node changes its active tip to a competing valid branch with more accumulated proof of work.
The node disconnects blocks from its old active branch back to the shared ancestor, then connects blocks from the stronger branch in order.
That process updates chainstate. Outputs created only in disconnected blocks can disappear from the active-chain UTXO set. Spends confirmed only in those blocks can become unconfirmed. Transactions from disconnected blocks may return to the node's mempool if they remain valid and satisfy current constraints.
Transactions in the newly connected branch become confirmed. Conflicting transactions from the old branch may no longer be valid.
A reorganization is not a rollback commanded by a central administrator. It is a local node changing its selected valid history as new work and block data arrive.
Confirmations measure selected-chain depth
A transaction has one confirmation when it appears in a block on the node's selected chain.
If one later block extends that chain, the transaction has two confirmations. Each additional block increases its depth below the selected tip.
Confirmations matter because replacing the transaction's block requires replacing that block and catching up with the work added after it. Deeper history generally requires more competing work to displace under ordinary assumptions.
Confirmation count is still not a universal finality guarantee.
Risk depends on:
- The value and reversibility of the transaction.
- The attacker's available hash power and duration.
- Whether the recipient controls its own node.
- Network connectivity and eclipse risk.
- The possibility of an accidental or deliberate reorganization.
- The transaction's conflict history.
- Operational and legal context outside Bitcoin.
A merchant selling a low-value digital item may accept a different threshold from an exchange settling a large withdrawal.
First inclusion is not immutability
A block explorer may label a transaction confirmed as soon as it enters a block.
That means the explorer's node currently sees the transaction on its selected chain. It does not mean the transaction can never leave that history.
Short reorganizations are a normal possibility in a distributed proof-of-work network. Deep reorganizations are much less common and generally more costly, but Bitcoin does not place an absolute finality flag on an ordinary transaction after a fixed number of blocks.
"Immutable" should be treated as a practical description of deeply buried, valid history under stated assumptions, not as an instant consensus state.
The precise language is that later proof of work makes replacement increasingly difficult.
Reorganizations do not rewrite transaction objects
A reorganization changes which blocks are selected.
It does not edit a confirmed transaction in place. A transaction from a disconnected block remains the same data structure. Its status changes because the block containing it is no longer on the active chain.
The transaction may:
- Appear in the new branch as well.
- Return to a mempool.
- Conflict with a transaction confirmed in the new branch.
- Become invalid under the new active-chain state.
- Be rebroadcast and confirmed later.
- Remain absent.
Wallets and services must respond to active-chain status rather than treating one observed block inclusion as permanent.
The active chain is not every valid block
A node can retain valid blocks that are not on its active chain.
These blocks can belong to stale branches, historical competitors, or branch tips the node is tracking. Their transactions are not considered confirmed merely because the blocks themselves were valid.
The word blockchain sometimes blurs this distinction. A node's block database can contain more blocks than the one selected chain. The active blockchain refers to the branch currently selected by accumulated work among valid candidates.
A block explorer may display stale blocks separately. Their presence demonstrates that validity and selection are separate questions.
Block height identifies position, not identity
Block height counts the position of a block relative to genesis.
Genesis has height 0. Its child has height 1, and so on.
Height is not a unique block identifier. Competing branches can contain different valid blocks at the same height. The block hash identifies the specific block.
This matters when software or users say "block 900,000," for example. A height points to the active-chain block in a particular node's current view unless a block hash or branch is specified.
During a reorganization, the block associated with a height can change.
Timestamps do not select the chain
Blocks contain timestamps, but nodes do not choose the chain with the newest-looking time.
Timestamps are constrained by consensus and are used in areas such as difficulty adjustment and time-based transaction rules. They remain miner-supplied values within permitted bounds.
Chain selection uses accumulated proof of work among valid candidates. A branch cannot win by placing a larger timestamp in its header.
Likewise, wall-clock age does not make an invalid branch acceptable.
Chainstate is derived from selected history
A full node does not need to replay every historical transaction for every new block.
During synchronization, it validates blocks and builds chainstate, including the current set of unspent transaction outputs. New transactions and blocks can then be checked against that current state.
When a block connects, spent outputs are removed and new outputs are added. Undo data helps a node disconnect retained blocks during a reorganization.
Chainstate is derived from validated history. It is not a substitute consensus authority.
A pruned node can discard eligible old raw block files after validation while retaining chainstate and continuing to enforce the same consensus rules. This is why a blockchain should not be defined as "a complete copy of every block stored by every node."
The blockchain does not contain every Bitcoin-related event
Bitcoin's selected chain records valid on-chain transactions and block data.
It does not directly record:
- Every transaction that was created but never confirmed.
- Every transaction that entered a mempool.
- Every attempted block header hash.
- Wallet labels or private keys.
- Exchange account balances.
- Lightning channel updates that remain off-chain.
- Real-world identities unless users or external systems connect them.
- Every stale block known to every node.
Applications can derive indexes and interpretations from blockchain data, but those views are not automatically consensus state.
Proof of work orders valid history
Proof of work gives nodes an objective way to compare valid branches without a central coordinator.
It does not tell nodes which rules to enforce. Node software and operator choices determine the rules used for validation.
This division is essential:
- Consensus rules determine which blocks are valid.
- Proof of work helps order valid competing histories.
- Network relay spreads candidate blocks.
- Chainstate tracks the effects of the selected history.
- Confirmations measure depth within that selected history.
Collapsing these roles produces slogans such as "miners control the blockchain" or "nodes vote on transactions." Neither is precise.
The selected history is durable because replacement is costly and detectable
Bitcoin's blockchain is durable through several reinforcing properties.
Hash links expose changes to earlier blocks. Proof of work makes rebuilding a competing branch costly. Independent nodes reject rule-breaking blocks. Wide peer connectivity helps valid blocks propagate. Confirmation depth increases the work an attacker must overcome.
None of these properties requires trusting one institution to maintain the ledger.
The result is not magical permanence. It is a continuously validated, work-ordered history whose replacement becomes increasingly difficult as valid blocks accumulate above it.
That is the useful meaning of the Bitcoin blockchain.