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.

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.”

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?