Anatomy of a Block

A block sounds like it should be a complicated object. It isn’t. A block is just two things glued together: an 80-byte header and an ordered list of transactions. The header is the part that gets mined and chained; the transaction list is the actual ledger update. Almost everything interesting about blocks falls out of understanding how those two pieces relate — and the secret is that the header doesn’t store the transactions at all. It stores a single 32-byte commitment to them. This page takes a block apart down to its bones.

The two-part shape

┌──────────────────────────────────────────────┐
│  BLOCK HEADER  (exactly 80 bytes)             │
│   version | prev block hash | merkle root |   │
│   timestamp | bits (target) | nonce           │
├──────────────────────────────────────────────┤
│  TRANSACTION COUNT  (a compact integer)       │
├──────────────────────────────────────────────┤
│  TRANSACTION 0  ← the coinbase (always first) │
│  TRANSACTION 1                                │
│  TRANSACTION 2                                │
│  ...                                          │
│  TRANSACTION n                                │
└──────────────────────────────────────────────┘

The header is fixed-size and tiny; the transaction list is variable and large (often a megabyte or more). The genius of the design is that the header commits to the whole transaction list through the Merkle root — one field, 32 bytes — so a miner only ever hashes the 80-byte header, never the megabyte of transactions. We give the header its own page: The Block Header.

The coinbase transaction comes first

The very first transaction in every block is special. It’s called the coinbase transaction (no relation to the company), and it is the only transaction allowed to create new coins from nothing. It has no real inputs — instead of spending a previous output, its single input points at a “null” reference and carries arbitrary data (the coinbase field, where Satoshi famously embedded a newspaper headline in the genesis block).

The coinbase output pays the miner two things added together:

Component	What it is
Block subsidy	Freshly minted coins (halves every 210,000 blocks)
Transaction fees	The sum of (inputs − outputs) of every other transaction in the block

Why the miner’s reward lives inside the block

The reward isn’t handed out by some external system — the miner writes their own payment into the block they mined. The rest of the network only accepts that payment if it obeys the rules (correct subsidy, fees that actually add up). So the incentive to mine and the verification of that incentive are both encoded in the same shared data structure. See Block Validation.

Committing to the transactions: the Merkle root

How does one 32-byte field in the header “contain” thousands of transactions? Each transaction is hashed; those hashes are paired and hashed again, and again, until a single hash remains at the top — the Merkle root. That root goes in the header. Change any transaction, even one byte, and the root changes, which changes the header, which changes the block’s hash. The transactions are therefore cryptographically welded to the header. We unpack the tree and its proofs in Merkle Trees & SPV, built on hash functions.

Size vs weight: vbytes and weight units

You might expect a block to be limited by its size in bytes. Historically it was — a flat ~1 MB cap. But the SegWit upgrade replaced that with a subtler limit: block weight, capped at 4,000,000 weight units (WU).

The trick is that not all bytes count equally:

weight = (non-witness bytes × 4) + (witness bytes × 1)

         ┌─────────────── "base" data (scripts, amounts, structure)
         │                 costs 4 WU per byte
         │
         └─────────────── "witness" data (signatures)
                           costs only 1 WU per byte   ← the discount

Witness data — chiefly signatures — is discounted 4×. The motivation is that signatures, once a transaction is buried in history, can be pruned by nodes that don’t need to re-verify ancient blocks; they’re less of a permanent burden on the UTXO set, so they’re priced lower. For convenience people divide weight by 4 to get virtual bytes (vbytes): vbytes = weight ÷ 4, so the cap is equivalently 1,000,000 vbytes.

Term	Meaning	Cap
Weight unit (WU)	Base byte = 4 WU, witness byte = 1 WU	4,000,000
Virtual byte (vbyte)	weight ÷ 4	1,000,000

This is why a block can sometimes hold more than 1 MB of raw data: a block stuffed with signature-heavy transactions carries lots of cheaply-weighted witness bytes. Fees are quoted in sats/vByte, so the weight system is also the foundation of Bitcoin’s fee market.

Why the size limit exists at all

A bigger block can hold more transactions — so why cap it? Because every full node on Earth must download, store, and verify every block. A small cap keeps the cost of running a node low enough that ordinary people can do it, which keeps verification decentralized. The limit is a deliberate trade of throughput for the ability of untrusting strangers to each check the ledger themselves.

By the numbers — how a block holds more than 1 MB

SegWit’s weight rule caps a block at 4,000,000 WU, but raw bytes can run well past the old 1 MB limit. Split a block into base bytes (×4 WU) and witness bytes (×1 WU) and the cap does the rest:

   weight = 4 × base_bytes + 1 × witness_bytes  ≤  4,000,000 WU

   Example:  base = 600,000 B,  witness = 1,600,000 B
   weight   = 4×600,000 + 1,600,000 = 2,400,000 + 1,600,000 = 4,000,000 WU   ✓ at the cap
   raw size = 600,000 + 1,600,000 = 2,200,000 B  ≈  2.2 MB

The theoretical ceiling is a block that is all witness data: 4,000,000 WU ÷ 1 ≈ 4 MB of raw bytes — roughly 4× the pre-SegWit 1 MB. In practice, witness-heavy blocks (signature-laden, or stuffed with inscription data) have approached ~4 MB while still sitting under the exact same weight cap.

The thread

How does this help untrusting strangers agree on one ledger? A block’s structure is what makes a batch of transactions into a single, atomic, checkable unit. The coinbase rule fixes exactly how many new coins may appear; the Merkle root welds the transaction list to the header so nothing can be swapped in or out unnoticed; the weight cap keeps verification cheap enough that thousands of independent strangers can each validate the same block and arrive at the same answer. The block is the quantum of agreement — the smallest packet of “here is the next chunk of history, and here is the proof you can trust it.”

The architect’s lens

Step back from the two-part shape and answer the five questions that turn an implementer into an architect:

• Why does it exist? To package a batch of transactions into one atomic, checkable unit — a tiny 80-byte header bolted to a variable-length transaction list, with the coinbase always first.
• What problem does it solve? It separates what gets mined from what gets stored: the header commits to the whole list through a single 32-byte Merkle root, so a miner hashes 80 bytes instead of a megabyte, and the coinbase rule fixes exactly how many new coins may appear.
• What are the trade-offs? The 4,000,000-weight-unit cap (≈1,000,000 vbytes) is the load-bearing compromise — it throttles throughput on purpose to keep full-node verification cheap, and the 4× witness discount adds a whole pricing layer (sats/vByte) most people find counterintuitive.
• When is a different design better? If your priority is raw throughput over universal verifiability, you’d raise or remove the weight cap (as big-block forks did) — trading the property that ordinary people can each run a node for more transactions per block.
• What breaks if I remove it? Drop the Merkle commitment and transactions could be swapped in or out unnoticed; drop the coinbase rule and minting becomes unbounded; drop the weight cap and node cost grows until only well-funded operators can validate — the chain centralizes.

Check your understanding

1. What are the two top-level parts of a block, and roughly how big is each?
2. Why does a miner only ever hash 80 bytes, even when the block holds a megabyte of transactions?
3. What makes the coinbase transaction unique, and what two components make up its output value?
4. Explain weight units and the witness discount. Why would a block sometimes exceed 1 MB of raw data while still fitting under the 4,000,000 WU cap?
5. Why is the block size/weight limit a decentralization decision rather than a mere technical detail?

Show answers

1. An 80-byte header (fixed, tiny) and an ordered list of transactions (variable and large, often a megabyte or more). The header is what gets mined and chained; the transaction list is the actual ledger update.
2. Because the header commits to the whole transaction list through one 32-byte field — the Merkle root — so the miner only ever hashes the 80-byte header, never the megabyte of transactions (The Block Header).
3. The coinbase transaction is the only transaction allowed to create new coins from nothing — it has no real inputs, just a null reference carrying arbitrary data. Its output pays the miner the block subsidy (freshly minted coins) plus the transaction fees (the sum of inputs − outputs of every other transaction).
4. Weight = (non-witness bytes × 4) + (witness bytes × 1), capped at 4,000,000 WU. Witness data (chiefly signatures) is discounted 4×, so a block stuffed with signature-heavy transactions carries lots of cheaply-weighted witness bytes and can exceed 1 MB of raw data while still fitting under the cap.
5. Because every full node must download, store, and verify every block. A small cap keeps the cost of running a node low enough that ordinary people can do it, which keeps verification decentralized — a deliberate trade of throughput for the ability of untrusting strangers to each check the ledger themselves.