What the Bitcoin blockchain is at the data level
In the simplest model, a blockchain is a chain of blocks. Each block has a header and transactions; the header contains the previous block's hash. Changing an old block changes its hash, so the reference in the next block no longer matches.
The data is not stored on one server. Copies are held by many nodes that can download, validate and reject blocks under the same rules. Consensus is not a vote for a preferred story; it is rule execution and selection of the chain with the greatest accumulated Proof of Work.
- a block has a header and transactions
- each header references the previous block hash
- a node can validate the chain locally
- the chain with the most accumulated work has priority
Block-header anatomy
A Bitcoin block header contains version, previous block hash, Merkle root, time, nBits and nonce. Together they form 80 bytes that a miner sends through double-SHA-256. Changing any field changes the hash result.
nBits is a compact target representation and nonce is only one search parameter. When the nonce range is exhausted, the miner changes coinbase and the Merkle root, updates time or receives a new pool job.
- version signals rules
- previous hash links the block
- Merkle root represents transactions
- nBits and nonce support Proof of Work
Merkle trees: compressing transactions into one root
To avoid putting every transaction in the header, Bitcoin hashes each transaction and then hashes pairs of neighboring values until one Merkle root remains. When a level has an odd number of items, the last hash is duplicated for the next level.
The benefit is a short inclusion proof. A user can verify that a transaction belongs to a block with the transaction, neighboring hashes and the root, without receiving every other transaction. This helps simplified clients, although they make additional trust assumptions.
- tree leaves are transaction IDs
- internal nodes are pair hashes
- the root enters the block header
- a Merkle proof proves inclusion without the full list
Transactions, inputs, outputs and UTXOs
A transaction does not say that an address balance became a number. It spends previous outputs and creates new ones. An input points to a previous txid and output index, while script and witness data prove that the spending condition is satisfied. An output sets an amount and scriptPubKey.
A UTXO exists until an accepted transaction spends it. The UTXO set is the state against which nodes compare a new transaction. That is why double-spending is detected as an attempt to reference an already-spent output, not as a conflict between two balance fields.
- UTXO is the state of unspent outputs
- an input points to an earlier output
- an output creates a new spending condition
- fee is inputs minus outputs
Transaction path: wallet to mempool
After signing, a transaction travels through the peer-to-peer network. Each node can have its own mempool, so there is no single global queue. A node checks format, scripts, signatures, UTXO availability, fee policy and conflicts with accepted transactions.
A transaction may appear in one explorer without being in a block. Miners build their own candidate blocks and usually favor higher fee rates. When demand rises, low-fee transactions may remain in mempools longer.
- mempool is local to each node
- mempool acceptance is not confirmation
- a miner builds its own candidate block
- fee rate is the price of block space
How Proof of Work selects a branch
If two miners find blocks at the same height almost simultaneously, different nodes may initially see different branches. When another block is found, one chain has more accumulated work. The shorter branch becomes stale or orphaned, and its transactions may return to the mempool if still valid.
The phrase longest chain is a shortcut. The important rule is greatest accumulated Proof of Work. Confirmations do not create instant immutability; they reduce the practical probability of a reorganization.
- short forks are normal in a distributed network
- a stale block is not automatically fraud
- consensus follows accumulated work
- chain depth is a practical reorg-risk signal
Confirmations, finality and double-spends
The first confirmation appears when a transaction enters an accepted block. The second appears when another block is built on top, and so on. Services choose their own confirmation policy based on amount and risk.
Bitcoin has probabilistic finality. A deep block could theoretically be reorganized, but an attacker would need to catch up in accumulated work. Before inclusion, conflicting unconfirmed transactions and replace-by-fee policy remain relevant.
- zero confirmations means not yet in an accepted block
- one confirmation means inclusion in a block
- later blocks increase the economic cost of reorg
- Bitcoin finality is probabilistic rather than instant
SPV, pruning and different ways to keep history
A full node can store the full chain and validate it from genesis. A pruned node deletes old full block data after validation while keeping state and metadata. An SPV client works primarily with headers and Merkle proofs and relies on network sources for some information.
These modes are not equivalent in independent verification. An explorer can provide indexes and APIs for convenient search, but a user should know whether the view comes from their own node, another API or an exchange database.
- a full node validates the full history
- a pruned node saves disk after validation
- SPV uses headers and Merkle proofs
- an explorer is an interface, not consensus
What a blockchain attack means in practice
Changing an old block changes its hash, breaks the next link and requires redoing Proof of Work for the rewritten branch. The attacker must also catch or overtake the honest chain. Cost depends on hashrate, time, power and block depth.
A 51% attack may enable censorship or double-spending of the attacker's own funds, but it does not provide private keys or force nodes to accept bad signatures or excess issuance. Nodes and Proof of Work protect different system boundaries.
- the previous hash creates a link
- Proof of Work makes rewriting expensive
- nodes reject invalid transaction rules
- security is not a price or exchange guarantee
How to read a block explorer
Start with height, hash, timestamp, previous hash, Merkle root, difficulty, nonce and block size. Then inspect transaction count, total fees, coinbase, weight and confirmations. For a transaction, inspect inputs, outputs, scripts or witness data, fee rate and inclusion block.
For mining, add economic context: block reward, network hashrate, difficulty, pool distribution and available block space. [SHA-256 in Bitcoin](sha-256-u-bitcoin) explains how the header becomes Proof of Work, while [mining pools](oglyad-mayning-puliv) explain how individual work becomes a payout.
- compare previous hash and height
- separate subsidy from fees
- read confirmations rather than only the timestamp
- do not treat an exchange balance as a UTXO
A Bitcoin block has two main parts
The header provides the link and Proof of Work; the body contains transactions.
From UTXO to confirmation
Funds change state through spending and new outputs, not through a central balance table.
Confirmation logic
Each new block adds work on top of the previous one, without instant absolute finality.
| Element | Role in the blockchain | What the node checks |
|---|---|---|
| Previous block hash | Links the block to its predecessor | Reference and predecessor match |
| Merkle root | Represents all transactions | Root matches the txid list |
| nBits / target | Sets the Proof of Work threshold | Double-SHA-256 is small enough |
| Coinbase | Creates allowed reward and may carry extraNonce | Subsidy does not exceed subsidy plus fees |
| UTXO set | Current state of spendable outputs | Inputs exist and are unspent |
| Mempool | Local set of unconfirmed transactions | Format, signatures, policy and conflicts |
| Confirmation | Transaction depth in the chain | How much work was added on top |
Real photos and source material
These photographs and diagrams are sourced from public archives. Open the source link to check the author and license.
Want to check the numbers for your ASIC right away?
Open calculator →
