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:
- Block header (80 bytes): Metadata and proof of work
- Transaction count (variable): CompactSize integer
- Transactions (variable): Ordered 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 |
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 the zero bytes at the end, while the 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 and Median Time Past)
The timestamp is a 32-bit unsigned integer representing seconds since the Unix epoch (January 1, 1970 00:00:00 UTC). The median time past (MTP) of a block is the median of the timestamps of the previous 11 blocks.
A valid block's timestamp must be strictly greater than the block's MTP, and must not exceed network-adjusted time plus 2 hours (both rules appear in the consensus catalog of Appendix D).
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.
Theorem 13.1 (Chain Integrity)
If block Bₙ contains prev_hash = H(B[n-1]),
then any modification to Bₙ₋₁ (including its transactions)
invalidates Bₙ and all subsequent blocks.
Proof.
Modifying any data in Bₙ₋₁ changes its header (via the Merkle root if transactions change, or directly if header fields change). Assuming H is collision-resistant, this changes H(Bₙ₋₁) except with negligible probability. Since Bₙ commits to the original hash, the link breaks. Repairing requires new proof of work for Bₙ 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 with typical transaction mixes (observed blocks average 1.5–2 MB), 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
- Block hash ≤ target (proof of work)
- Version is acceptable (not rejected by majority)
- Timestamp > median of last 11 blocks
- Timestamp < current time + 2 hours
- Previous block hash references a known valid block
- Bits matches expected difficulty
Transaction Rules
- At least one transaction (the coinbase)
- First transaction is coinbase; no others are
- All transactions are valid
- No double-spends within the block
- No double-spends with existing UTXO set
- Merkle root matches computed root
Size Rules
- Block weight ≤ 4,000,000 WU
- Block serialization ≤ protocol limits
Coinbase Rules
- Coinbase outputs ≤ subsidy + fees
- Coinbase contains block height (BIP-34)
- 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...da33b |
| 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 was not 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
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.)
13.9 Block Propagation
For the network to function, new blocks must propagate quickly to all nodes.
Definition 13.16 (Mempool)
A node's mempool (memory pool) is its set of valid, unconfirmed transactions—received from the network but not yet included in a block. Each node maintains its own mempool; there is no single global one.
Definition 13.17 (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.
Network Protocol Constants
The peer-to-peer layer has constants of its own: the default mainnet
port (8333; testnet uses 18333), the four "magic" bytes that prefix
every message (0xF9BEB4D9 on mainnet), and caps on message
size (4 MB) and on entries per inv announcement (50,000).
None of these is a consensus parameter in the sense of Definition 16.1:
a node that changes them can still validate, and follow, the same chain.
We record them here, with the networking machinery, to keep that
distinction sharp; the consensus constants proper are the subject of
Chapter 15.
13.10 The Validation Function
The validation rules of Section 13.5 are more than a checklist: collectively they define a mathematical object that the rest of this book builds on. Every statement about consensus—and, in Chapter 26, the entire theory of forks—reduces to questions about a single predicate.
Definition 13.18 (Validation Predicate)
The validation predicate is a function
V(C, B) ∈ {accept, reject}
where B is a candidate block and C is the chain state it would extend: the header chain (which fixes the height, the expected difficulty, and the median time past), the UTXO set, and the set of rules active at that height. The set of valid blocks at state C is
R(C) = { B : V(C, B) = accept }.
V must be a pure, deterministic function: identical inputs must produce identical verdicts on every node, regardless of hardware, operating system, or local configuration. Consensus is exactly the property that all participants compute the same V.
Definition 13.19 (The Validation Pipeline)
In practice V decomposes into four phases, ordered so that cheap, context-free checks reject invalid blocks before expensive, state-dependent ones run:
- Header validation: the proof of work meets the target encoded in bits; that target equals the value prescribed by the difficulty adjustment; the timestamp exceeds the median time past and does not run more than two hours ahead of network-adjusted time; the version satisfies any height-gated minimum.
- Transaction validation (context-free): each transaction has inputs and outputs, respects size and value bounds, and contains no duplicate inputs; checks that need no knowledge of the chain.
- Block-structure validation: the Merkle root matches the transaction list, the first and only the first transaction is a coinbase, the block respects the weight and signature-operation limits, and the transaction list admits no duplicate-subtree mutation.
- Contextual validation and connection: the state-dependent rules—transaction finality, the coinbase height commitment, the witness commitment, existence and maturity of every spent output, value conservation, sequence locks, and script execution under the flags active at this height.
The complete rule catalog, phase by phase with activation heights, is collected in Appendix D.
Remark 13.5 (Height-Gated Rules)
Each rule carries an activation condition: BIP-34's height commitment binds from height 227,931, SegWit's witness commitment from 481,824, Taproot's script rules from 709,632. The predicate V is therefore a function of height as well as content, and the valid set R(C) shrinks at every soft-fork activation—the formal content of Chapter 16's definition of a soft fork, and the foundation of the rule-set analysis in Chapter 26.
Remark 13.6 (Determinism as a Consensus Requirement)
The purity requirement in Definition 13.18 is not a stylistic preference. Any input to V beyond (C, B)—a database resource limit, available memory, an environment-dependent code path—is a latent consensus failure: two honest nodes can disagree about R(C) without either being modified. Exactly this happened in March 2013, when an implicit resource limit acted as an unwritten validation rule (Section 33.9 examines the episode as a specification failure).
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...5e4a (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).