How the Bitcoin blockchain records every transaction

A linked history

Every block commits to the prior block's hash, making edits visible and requiring subsequent proof of work to be redone. The chain is a transaction-ordering mechanism, not a general-purpose database for every kind of data. <strong>Validation before acceptance.</strong> Nodes do not trust a block because a miner produced it. They verify proof of work and every consensus rule.

An invalid block is rejected even if creating it consumed substantial energy. <strong>Why block space is scarce.</strong> Bounded capacity helps ordinary operators validate the chain and limits resource growth. When demand exceeds space, users compete through fees and can move suitable activity to higher layers.

What this establishesHashes make historical tampering evident.

What changing an old block would require

Imagine altering one transaction in a block that already has six blocks built above it. The edited transaction would change the block's Merkle root, which would change its header hash. The next block would no longer point to the same previous hash.

Every later header would therefore need to be rebuilt with new proof of work while the honest network continued adding blocks to the accepted chain. This is why a blockchain is not made immutable by a database permission. Its history becomes progressively more expensive to replace.

Nodes still check that every replacement block is valid, so accumulated work cannot make an invalid subsidy or signature acceptable. The practical security of a payment depends on confirmation depth, current competing work, and the value at risk, not on the vague statement that blockchains cannot be changed.

What this establishesNodes verify miners, not the other way around.

Anatomy of a block

Every block begins with an 80-byte header: a version, the hash of the previous block's header, a Merkle root committing to every transaction inside, a timestamp, the encoded difficulty target and a nonce. The header is what miners hash. Behind it sit the transactions, the first of which is the coinbase transaction that creates the subsidy and collects the fees.

Because the Merkle root binds the transactions to the header and the previous-hash field binds each header to the one before, a single 32-byte value at the tip commits to the entire history back to January 2009.

What this establishesLimited block space supports verifiability and creates a fee market.

Immutability is a cost, not a lock

Nothing physically prevents someone from producing an alternative block. What prevents it from mattering is that nodes follow the valid chain with the most accumulated proof of work, and producing a competing chain means redoing the work for every block you want to replace, faster than the honest network extends the real one.

At the current hashrate that is infeasible for anything more than a block or two. This is why 'immutable' really means 'economically irreversible' and why the depth of a transaction, measured in confirmations, is the right way to think about its finality.

Forks, reorganisations and what nodes do about them

Occasionally two miners find a block at nearly the same moment and the network briefly sees two tips. Nodes keep both, extend whichever they saw first, and switch to whichever chain grows longer - a reorganisation of one block, which happens a few times a year and is why a single confirmation is not treated as final.

A hard fork is different: a rule change that old nodes reject. Bitcoin Cash in 2017 was one. The chain that keeps the name is simply the one most nodes, miners, exchanges and users continue to follow, which is a social fact enforced by software rather than the other way round.