Anatomy of a Bitcoin block: the header, the coinbase and the weight limit, using block 0

A block is a short header and a long list of transactions

Strip away the mystique and a block is a small, fixed-size header followed by however many transactions the miner chose to include. The header is 80 bytes, a size the white paper gives in passing when it estimates that headers alone would add up to 4.2 megabytes a year at one block every ten minutes. Everything that makes a block a block, the proof-of-work, the link to the previous block, the fingerprint of its contents, lives in those 80 bytes. The transactions are the cargo.

When people talk about a block’s hash, they mean the hash of the header only. Miners hash the header repeatedly, and the developer guide notes that each block header must hash to a value below the target threshold. The transactions are not hashed directly during mining; they are represented in the header by a single 32-byte summary, which is what lets a miner try enormous numbers of header variations without touching the transaction list. Our what is a blockchain article explains how those headers chain together.

The six header fields, read off block 0

The developer reference lists the header fields in order. Version, four bytes, says which validation rules the block follows. Previous block header hash, 32 bytes, is the hash of the block before, which the reference says ensures no previous block can be changed without also changing this block’s header. Merkle root, 32 bytes, is derived from the hashes of all the transactions in the block. Time, four bytes, is the Unix time when the miner started hashing, and it must be greater than the median time of the previous eleven blocks. nBits, four bytes, is the encoded target the header hash must fall below. Nonce, four bytes, is an arbitrary number miners change to alter the hash.

Block 0, the genesis block, makes a good worked example because a block explorer shows every field and there is only one transaction to think about. Its version is 1. It has no previous block to point to; the Bitcoin Wiki notes that it does not reference a previous block. Its Merkle root is simply the identifier of its one transaction, which begins 4a5e1e. Its time is 1231006505, which is 3 January 2009 at 18:15:05 UTC. Its nBits value is 0x1d00ffff, the easiest target the main network allows, which the developer reference identifies as difficulty 1, and the explorer reports its difficulty as exactly 1. Its nonce is 2083236893.

One oddity: the wiki points out that the genesis block’s hash has two more leading zeros than an early block needed, meaning Satoshi found a hash far below the target, and that the next block’s timestamp is a full six days later. Nobody knows why. The header records what happened, not what was intended.

The coinbase transaction is where new bitcoin comes from

The white paper says that by convention the first transaction in a block is a special one that starts a new coin owned by the block’s creator. That is the coinbase transaction. Unlike every other transaction, it spends nothing. The developer reference describes its single input as pointing at a 32-byte null with an index of 0xffffffff, a placeholder meaning no previous output, followed by a script of between 2 and 100 bytes that the miner fills in more or less as it likes.

Since BIP34, proposed by Gavin Andresen on 6 July 2012, that script must begin with the block’s height, so that no two coinbase transactions can be identical. The developer reference notes that blocks before height 227,836 did not require it, and BIP34 records that block 227,835, on 24 March 2013, was the last version 1 block. The rest of the space is arbitrary data. Miners commonly put an extra nonce there, which changes the Merkle root and gives them a fresh header to search when the four-byte nonce runs out. Some also leave messages. Satoshi did: block 0’s coinbase carries the text “The Times 03/Jan/2009 Chancellor on brink of second bailout for banks.”

The coinbase output collects the block reward and every fee in the block, and it comes with a waiting period: the developer guide states that a coinbase output cannot be spent for at least 100 blocks. Block 0’s single output was 50 bitcoin, and it has never moved, because, as the wiki explains, a quirk in how the genesis block is expressed in the code means it cannot be spent. Whether that was deliberate is unknown. The coins sit at the address recorded in our genesis block coinbase dossier.

The Merkle root ties every transaction to the header

The developer guide describes how the root is built. Each transaction identifier is paired with another and the pair is hashed together; if there is an odd number, the one without a partner is hashed with a copy of itself. The resulting hashes are paired and hashed again, and so on, until one hash remains: the Merkle root. The coinbase transaction’s identifier always goes first. Change one byte of one transaction and the root changes, which changes the header, which changes the block hash, which would no longer satisfy the proof-of-work.

The white paper introduced the structure for a practical reason: disk space. Old transactions could be pruned away while the root in the header stayed valid, and a light client could check that a transaction was in a block by asking for the short branch of hashes linking it to the root, without downloading the block. That is the Merkle branch in the paper’s payment-verification section, and it is why a phone wallet can confirm a payment while holding only headers. The nodes article covers what a light client gives up by doing so.

Size versus weight: how big a block can be

Originally Bitcoin had one limit: BIP141 records that blocks were limited to 1,000,000 bytes. The Segregated Witness upgrade, specified in that BIP by Eric Lombrozo, Johnson Lau and Pieter Wuille, replaced the byte count with a new measure. Block weight is the base size, meaning the block serialized the old way without signature data, times three, plus the total size including that data. A block’s weight must be no more than 4,000,000 units.

The effect is that signature data counts a quarter as much as everything else, which is why a block can be larger than a megabyte on disk while its weight stays under the cap. Block 0 makes the arithmetic visible. It is 285 bytes and has no witness data, so its base size and total size are the same, and its weight is 285 times three plus 285, which is 1,140, exactly what the explorer reports. A transaction’s virtual size, the number wallets use when they quote fees in satoshis per virtual byte, is its weight divided by four, rounded up to a whole virtual byte.

That limit was the subject of a years-long argument covered in the block size war dossier, and it is the reason fees rise when demand does. The SegWit article explains where witness data went and why. If you want to inspect any of these fields yourself, our guide to reading a block explorer shows where each one appears.