What the blockchain stores, why it is intentionally limited and how nodes agree on its history. The explanation names what wallets, nodes, and miners each do so their roles do not blur together.
- Hashes make historical tampering evident.
- Nodes verify miners, not the other way around.
- Limited block space supports verifiability and creates a fee market.
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.
Validation before acceptance
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.
Name the layer and the actor. Wallets create transactions, nodes check rules, miners propose blocks, and Lightning peers manage channels.
Why block space is scarce
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.
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.
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.
Trace the rule through the network
Follow one transaction from wallet signing to node validation, mempool relay, block inclusion, and confirmations. That sequence shows which facts come from consensus and which depend on local policy.
Common questions
What is inside a block?
An 80-byte header — version, previous block hash, Merkle root, timestamp, difficulty target and nonce — followed by the transactions. The Merkle root commits to every transaction, so changing any of them changes the header and breaks the chain.
Why can't the blockchain be edited?
Each block's hash is built from its contents and the previous block's hash. Altering an old transaction changes that block's hash, which invalidates every block after it, so an attacker would have to redo all of that proof of work faster than the rest of the network extends the chain.
How large is the blockchain?
Several hundred gigabytes and growing by roughly 50–100 GB a year. A node can run in pruned mode, keeping only recent blocks and the current set of spendable outputs, which needs a few gigabytes while still validating everything.
Sources and further reading
Primary documents this guide draws on. Links open the original publisher.
- Developer guide: block chain developer.bitcoin.org
- Reference: block chain developer.bitcoin.org
- Block Bitcoin Wiki
- Bitcoin: A Peer-to-Peer Electronic Cash System Satoshi Nakamoto, 2008