Chapter 13

Blocks

The Fundamental Unit of Consensus

A Bitcoin block is a container that bundles transactions together with a header that commits to the block's contents and links it to its predecessor. Blocks are the atoms of consensus: nodes agree on the state of Bitcoin by agreeing on which blocks are valid and which chain of blocks is canonical.

In this chapter, we examine the precise structure of blocks, the validation rules they must satisfy, and how they chain together to form the blockchain.

13.1 Block Structure

A Bitcoin block consists of two parts: a compact header and a list of transactions.

Definition 13.1 (Block)

A block is a data structure containing:

  1. Block header (80 bytes): Metadata and proof of work
  2. Transaction count (variable): CompactSize integer
  3. Transactions (variable): Ordered list of transactions
Bitcoin Block Block Header 80 bytes · Fixed size Tx Count Transactions Coinbase Tx 1 Tx 2 ... Tx n-1 Tx n
Figure 13.1: A block contains a fixed-size header and a variable-size list of transactions.

13.2 The Block Header

The block header is the most critical 80 bytes in Bitcoin. It contains all information needed to validate the block's place in the chain and verify the proof of work.

Definition 13.2 (Block Header)

A block header consists of six fields totaling exactly 80 bytes:

Field Size Description
Version 4 bytes Block version number
Previous Block Hash 32 bytes Hash of the previous block header
Merkle Root 32 bytes Root of the transaction Merkle tree
Timestamp 4 bytes Unix time (seconds since 1970-01-01)
Bits 4 bytes Difficulty target (compact format)
Nonce 4 bytes Counter for proof-of-work mining
version 4B prev_block_hash 32B merkle_root 32B time 4B bits 4B nonce 4B Total: 80 bytes
Figure 13.2: The six fields of a block header, all stored in little-endian format.

13.2.1 Version

The version field signals support for consensus rule changes and soft forks.

Definition 13.3 (Version Bits)

Block versions follow BIP-9 version bits signaling. The top 3 bits are set to 001, and the remaining 29 bits can signal readiness for various soft forks.

13.2.2 Previous Block Hash

This field creates the chain structure by referencing the parent block.

Definition 13.4 (Block Hash)

The block hash is computed as:

block_hash = SHA256(SHA256(header))

where header is the 80-byte block header.

Remark 13.1 (Hash Display Convention)

Block hashes are typically displayed in big-endian (reversed) format for readability. The internal little-endian format has leading zeros at the end, while display format has them at the beginning.

13.2.3 Merkle Root

The Merkle root commits to all transactions in the block, as detailed in Chapter 12.

13.2.4 Timestamp

Definition 13.5 (Block Timestamp)

The timestamp is a 32-bit unsigned integer representing seconds since the Unix epoch (January 1, 1970 00:00:00 UTC).

Theorem 13.1 (Timestamp Constraints)

A valid block timestamp must satisfy:

  • Greater than the median of the previous 11 blocks (MTP)
  • Less than 2 hours in the future (network-adjusted time)

13.2.5 Bits (Difficulty Target)

The bits field encodes the difficulty target in a compact format.

Definition 13.6 (Compact Target)

The compact target format encodes a 256-bit target in 4 bytes:

target = coefficient × 256^(exponent - 3)

where bits = exponent || coefficient (1 byte + 3 bytes).

Example 13.1 (Decoding Bits)

Given bits = 0x1d00ffff (genesis block): 

exponent = 0x1d = 29
coefficient = 0x00ffff

target = 0x00ffff × 256^(29-3)
       = 0x00ffff × 256^26
       = 0x00000000ffff0000...0000 (with many trailing zeros)

13.2.6 Nonce

The nonce is the "free" field that miners vary to search for a valid proof of work.

Definition 13.7 (Nonce)

The nonce is a 32-bit unsigned integer (0 to 2³² − 1) that miners increment while searching for a block hash below the target.

Remark 13.2 (Extra Nonce)

With modern hash rates, 2³² nonces are insufficient. Miners also vary the coinbase transaction (changing the Merkle root) and the timestamp to expand the search space. This "extra nonce" effectively provides unlimited attempts.

13.3 Block Hashing and the Chain

The blockchain is formed by each block referencing its predecessor's hash.

Block n−2 prev: ...abc hash: ...def Block n−1 prev: ...def hash: ...789 Block n prev: ...789 hash: ...xyz Each block's prev_hash = parent's block_hash
Figure 13.3: Blocks form a chain through hash references.

Theorem 13.2 (Chain Integrity)

If block B_n contains prev_hash = H(B_{n-1}), then any modification to B_{n-1} (including its transactions) invalidates B_n and all subsequent blocks.

Proof.

Modifying any data in B_{n-1} changes its header (via the Merkle root if transactions change, or directly if header fields change). This changes H(B_{n-1}). Since B_n commits to the original hash, the link breaks. Repairing requires new proof of work for B_n and all descendants. □

13.4 Block Size and Weight

Bitcoin limits block size to prevent resource exhaustion attacks.

13.4.1 Legacy Block Size Limit

Definition 13.8 (Block Size Limit)

Prior to SegWit, the block size limit was:

block_size ≤ 1,000,000 bytes (1 MB)

13.4.2 Block Weight (SegWit)

SegWit replaced the size limit with a weight limit, providing a discount for witness data.

Definition 13.9 (Block Weight)

The block weight is calculated as:

weight = (base_size × 3) + total_size

where base_size excludes witness data and total_size includes it.

The limit is:

weight ≤ 4,000,000 weight units (4 MWU)

Example 13.2 (Block Weight Calculation)

A block with:

  • Base size: 750,000 bytes
  • Witness size: 500,000 bytes
  • Total size: 1,250,000 bytes
weight = (750,000 × 3) + 1,250,000
       = 2,250,000 + 1,250,000
       = 3,500,000 WU  (valid: < 4,000,000)

Remark 13.3 (Effective Size Increase)

The weight system allows blocks up to approximately 2.3 MB in practice (with typical transaction mixes), while maintaining backward compatibility with the 1 MB limit for non-witness data.

13.5 Block Validation Rules

A block must satisfy numerous rules to be considered valid.

Definition 13.10 (Block Validity)

A block is valid if and only if all of the following hold:

Header Rules

  1. Block hash ≤ target (proof of work)
  2. Version is acceptable (not rejected by majority)
  3. Timestamp > median of last 11 blocks
  4. Timestamp < current time + 2 hours
  5. Previous block hash references a known valid block
  6. Bits matches expected difficulty

Transaction Rules

  1. At least one transaction (the coinbase)
  2. First transaction is coinbase; no others are
  3. All transactions are valid
  4. No double-spends within the block
  5. No double-spends with existing UTXO set
  6. Merkle root matches computed root

Size Rules

  1. Block weight ≤ 4,000,000 WU
  2. Block serialization ≤ protocol limits

Coinbase Rules

  1. Coinbase outputs ≤ subsidy + fees
  2. Coinbase contains block height (BIP-34)
  3. Witness commitment present if SegWit transactions exist

13.6 The Genesis Block

The blockchain begins with a special hardcoded block: the genesis block.

Definition 13.11 (Genesis Block)

The genesis block is block 0 of the Bitcoin blockchain. It is hardcoded into every Bitcoin implementation and serves as the root of the chain.

Example 13.3 (Genesis Block Details)

Block Hash: 

000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f

Header Fields:

Version 1
Previous Hash 0000...0000 (all zeros)
Merkle Root 4a5e1e...b9b63
Timestamp 2009-01-03 18:15:05 UTC
Bits 0x1d00ffff
Nonce 2083236893

Coinbase Message:

"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"

Remark 13.4 (Genesis Block Peculiarities)

The genesis block has several unique properties:

  • Its coinbase output (50 BTC) is unspendable due to a quirk in the original code
  • The embedded newspaper headline proves the block wasn't pre-mined
  • Its previous hash is all zeros (no parent)

13.7 Block Height and Depth

Definition 13.12 (Block Height)

The block height is the number of blocks between a given block and the genesis block. The genesis block has height 0.

Definition 13.13 (Confirmation Depth)

The confirmation depth of a transaction is one plus the number of blocks built on top of the block containing it:

confirmations = chain_tip_height − tx_block_height + 1

Height 0 Genesis Height 1 ... Height n Tx here n+1 n+2 Tip 3 confirmations
Figure 13.4: A transaction at height n has 3 confirmations when the chain tip is at n+2.

13.8 Orphan and Stale Blocks

Not all valid blocks become part of the main chain.

Definition 13.14 (Stale Block)

A stale block is a valid block that is not part of the longest (most-work) chain. This occurs when two miners find blocks at approximately the same time, and one chain eventually "wins."

Definition 13.15 (Orphan Block)

An orphan block is a block whose parent is unknown. (Note: terminology varies; some use "orphan" for stale blocks.)

n−1 n n+1 n+2 n+1' stale Main chain (most work)
Figure 13.5: Block n+1' is valid but stale—the main chain extended differently.

13.9 Block Propagation

For the network to function, new blocks must propagate quickly to all nodes.

Definition 13.16 (Compact Blocks)

Compact block relay (BIP-152) reduces block propagation bandwidth by sending only short transaction IDs. Receiving nodes reconstruct the block from their mempool.

Fast propagation reduces stale block rates and improves mining fairness. Modern optimizations achieve sub-second propagation for most blocks.

Exercises

Exercise 13.1

Calculate the block hash for a header with the following fields (all in hex): 

version: 01000000
prev_hash: 0000...0000 (32 bytes of zeros)
merkle_root: 3ba3...f63 (32 bytes)
time: 29ab5f49
bits: ffff001d
nonce: 1dac2b7c

Verify it matches the genesis block hash.

Exercise 13.2

A block has base size 800 KB and witness size 400 KB. Calculate its weight. Is it valid under the 4 MWU limit?

Exercise 13.3

Why is the 80-byte header size significant? What would be the implications if the header were 1 KB instead?

Exercise 13.4

Explain why modifying a transaction in block 500,000 would require re-mining all subsequent blocks. What is the economic significance?

Exercise 13.5

The genesis block coinbase has 50 BTC but cannot be spent. Research why this is the case (hint: look at how the original code handled the genesis block).