Bitcoin Block Structure: Anatomy of a Block

Every ten minutes, on average, a new block is appended to the Bitcoin blockchain. This block is a carefully structured data container that encapsulates transactions, links to the previous block through cryptographic hashing, and embeds the proof that computational work was performed to create it. Understanding the exact structure of a block — byte by byte — is fundamental to understanding how Bitcoin achieves its properties of immutability, decentralization, and trustless verification.

A Bitcoin block consists of two primary components: the block header (exactly 80 bytes) and the block body (variable size, containing the transactions). Together, they form the atomic unit of the blockchain — the indivisible record that, once buried under subsequent blocks, becomes practically irreversible.

The Block Header: 80 Bytes That Secure the Chain

The block header is the most information-dense structure in Bitcoin. In just 80 bytes, it encodes six fields that collectively provide chain linkage, transaction integrity verification, timestamp information, difficulty targeting, and the proof-of-work nonce. Miners hash this 80-byte header repeatedly, searching for a hash that falls below the current target.

Field-by-Field Breakdown

Field	Size	Description
Version	4 bytes	Block version number, indicates which validation rules to follow
Previous Block Hash	32 bytes	SHA-256d hash of the previous block’s header
Merkle Root	32 bytes	Root hash of the Merkle tree of all transactions in the block
Timestamp	4 bytes	Unix time (seconds since 1970-01-01 00:00:00 UTC)
Bits (Target)	4 bytes	Compact representation of the difficulty target
Nonce	4 bytes	Counter that miners increment to find a valid hash
Total	80 bytes

Version (4 bytes)

The version field was originally intended to signal protocol upgrades. Block version 1 was used from the genesis block through 2012. Version 2 was introduced with BIP-34, requiring the block height in the coinbase transaction. Version 3 (BIP-66) enforced strict DER encoding for signatures. Version 4 (BIP-65) activated OP_CHECKLOCKTIMEVERIFY.

Since BIP-9 (2016), the version field has been repurposed for “version bits” signaling. Instead of incrementing sequentially, individual bits within the version field can be set to signal support for specific soft fork proposals. Bits 0-28 are available for signaling, while the top three bits must be set to 001 (making the version appear as 0x20000000 or higher). This mechanism was used to signal Taproot activation (BIP-341) through bit 2, producing version values like 0x20000004.

Previous Block Hash (32 bytes)

This field contains the double-SHA-256 hash of the preceding block’s 80-byte header. It is the chain in blockchain — the cryptographic link that makes the data structure a linear, ordered sequence of blocks.

The hash is stored in internal byte order (little-endian), which is the reverse of the human-readable format displayed by block explorers. For example, the genesis block’s hash:

• Display format: 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
• Internal byte order (as stored in the next block’s header): 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000

This field creates the immutability guarantee: changing any data in a past block changes that block’s hash, which invalidates the previous-block-hash field in the next block, cascading forward through every subsequent block. To alter historical data, an attacker would need to re-mine every block from the altered one to the chain tip — an impossibility given sufficient depth.

Merkle Root (32 bytes)

The Merkle root is the apex of a binary hash tree constructed from all transactions in the block. It provides a compact, tamper-evident summary of the block’s transaction set.

The construction process:

1. Each transaction is hashed with double-SHA-256 to produce a leaf hash (the txid)
2. Adjacent leaf hashes are concatenated and hashed again to produce parent nodes
3. If there is an odd number of nodes at any level, the last node is duplicated
4. This process continues upward until a single 32-byte root remains

The Merkle root enables Simplified Payment Verification (SPV): a lightweight client can verify that a specific transaction is included in a block by requesting only the Merkle proof (a small set of hashes along the path from the transaction to the root), rather than downloading the entire block. For a block with 2,000 transactions, the proof requires only about 11 hashes (log₂(2000) ≈ 11) — roughly 352 bytes instead of several megabytes.

Timestamp (4 bytes)

The timestamp is an unsigned 32-bit integer representing the number of seconds since the Unix epoch (January 1, 1970, 00:00:00 UTC). Miners set this value, but it is subject to validation rules:

• The timestamp must be greater than the median of the previous 11 blocks (Median Time Past, or MTP)
• The timestamp must not be more than 2 hours ahead of the node’s local time

These rules allow for some flexibility (block times are not perfectly accurate) while preventing miners from manipulating timestamps dramatically. The MTP rule, introduced in BIP-113, is particularly important because it is used to evaluate time-based transaction lock conditions (OP_CHECKLOCKTIMEVERIFY).

The 32-bit timestamp will overflow on February 7, 2106, at 06:28:15 UTC. This is known as the “Year 2106 problem” for Bitcoin and will require a protocol change before that date — though 80 years is ample time for planning.

Bits / Target (4 bytes)

The bits field encodes the proof-of-work difficulty target in a compact format. The target is a 256-bit number; hashes below this target are considered valid proof-of-work. The compact encoding uses 4 bytes to represent this large number.

The encoding format is:

bits = 0xAABBCCDD
exponent = AA
coefficient = 0x00BBCCDD

target = coefficient × 2^(8 × (exponent - 3))

For example, the bits value 0x170c7c60 (from block 860,000):

• Exponent: 0x17 = 23
• Coefficient: 0x0c7c60
• Target: 0x0c7c60 × 2^(8 × (23 - 3)) = 0x0c7c60 × 2^160

The difficulty retargets every 2,016 blocks (approximately every two weeks). If the previous 2,016 blocks were mined faster than the expected 20,160 minutes (10 minutes × 2,016), the target decreases (difficulty increases). If slower, the target increases (difficulty decreases). The adjustment is clamped to a maximum factor of 4× in either direction to prevent drastic swings.

Nonce (4 bytes)

The nonce (number used once) is the field that miners iterate to search for a valid proof-of-work. Starting from 0 and incrementing through all 2³² (approximately 4.3 billion) possible values, the miner computes SHA-256d(header) for each nonce value, checking whether the result is below the target.

With modern mining hardware processing hundreds of terahashes per second (TH/s), the 4-byte nonce space (4.3 billion possibilities) is exhausted in a fraction of a second. Miners must therefore vary other header fields to create new nonce search spaces:

• Timestamp: Can be incremented by 1 second
• Coinbase extra nonce: Modifying the coinbase transaction changes the Merkle root, creating an entirely new search space
• Version bits: Unused version bits can be rolled

The extraNonce technique in the coinbase transaction is the primary method for expanding the search space. By changing even a single byte in the coinbase, the entire Merkle tree changes, producing a completely new set of 4.3 billion nonce values to test.

Hex Breakdown of a Real Block Header

Let us dissect block 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f — the genesis block (block 0), mined by Satoshi Nakamoto on January 3, 2009.

The raw 80-byte header in hexadecimal:

01000000                                 # Version: 1
0000000000000000000000000000000000000000
00000000000000000000000000000000         # Previous Block Hash: all zeros (no predecessor)
3ba3edfd7a7b12b27ac72c3e67768f617fc81bc3
888a51323a9fb8aa4b1e5e4a               # Merkle Root
29ab5f49                                 # Timestamp: 1231006505 (2009-01-03 18:15:05 UTC)
ffff001d                                 # Bits: 0x1d00ffff (initial difficulty)
1dac2b7c                                 # Nonce: 2083236893

Parsing each field:

Version 01000000 → little-endian for integer 1. This is block version 1.

Previous Block Hash 0000...0000 → 32 bytes of zeros. The genesis block has no predecessor. This is the only block in the chain where this field is all zeros.

Merkle Root 3ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a → The hash of the single transaction (the coinbase) in the genesis block. Since there is only one transaction, the Merkle root is simply the double-SHA-256 of that transaction.

Timestamp 29ab5f49 → little-endian for 0x495fab29 = 1231006505 decimal. This corresponds to Saturday, January 3, 2009, 18:15:05 UTC. This is the moment Bitcoin was born.

Bits ffff001d → little-endian for 0x1d00ffff. This encodes the initial difficulty target: 0x00ffff × 2^(8 × (0x1d - 3)) = 0x00000000FFFF0000000000000000000000000000000000000000000000000000. This is the easiest target Bitcoin has ever used — appropriate for a network with a single miner.

Nonce 1dac2b7c → little-endian for 0x7c2bac1d = 2083236893 decimal. Satoshi iterated through over 2 billion nonce values before finding one that produced a hash below the target.

The double-SHA-256 of this 80-byte header produces the genesis block hash: 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f

Note the leading zeros — this is visual evidence of proof-of-work. The number of leading zeros reflects the difficulty target.

The Block Body

Below the header lies the block body, containing the actual transactions. The body begins with a variable-length integer (varint) indicating the transaction count, followed by the serialized transactions themselves.

Transaction Count

The transaction count is encoded as a Bitcoin varint (compact size encoding):

• 0x00-0xFC: 1 byte (value as-is)
• 0xFD: 3 bytes (0xFD followed by 2-byte little-endian value)
• 0xFE: 5 bytes (0xFE followed by 4-byte little-endian value)
• 0xFF: 9 bytes (0xFF followed by 8-byte little-endian value)

A typical block in 2026 contains 2,000-4,000 transactions. A count of 3,000 (0x0BB8) would be encoded as FDB80B.

The Coinbase Transaction

The first transaction in every block is the coinbase transaction (also called the generation transaction). This is the only transaction type in Bitcoin that creates new coins — it has no real inputs and produces outputs that award the block reward to the miner.

The coinbase transaction has a distinctive structure:

Input: A single input with the following special properties:

• Previous transaction hash: 32 bytes of zeros (0x0000…0000) — there is no previous transaction to spend
• Previous output index: 0xFFFFFFFF — the maximum value, indicating this is not a real output reference
• Coinbase data (scriptsig): Up to 100 bytes of arbitrary data. Since BIP-34 (block version 2), the first bytes must encode the block height as a script number. The remaining space is used by mining pools to include their pool identifier, an extraNonce for expanding the mining search space, and occasionally messages

Satoshi famously embedded the text “The Times 03/Jan/2009 Chancellor on brink of second bailout for banks” in the genesis block’s coinbase data — a headline from The Times of London that serves as both a timestamp proof and a political statement about the monetary system Bitcoin was designed to replace.

Outputs: The coinbase outputs can send the block reward (subsidy + fees) to any address or set of addresses. The block subsidy follows the halving schedule:

• Blocks 0-209,999: 50 BTC
• Blocks 210,000-419,999: 25 BTC
• Blocks 420,000-629,999: 12.5 BTC
• Blocks 630,000-839,999: 6.25 BTC
• Blocks 840,000-1,049,999: 3.125 BTC (current epoch as of 2026)

The coinbase transaction has a special maturity rule: its outputs cannot be spent until 100 additional blocks have been mined on top of the block containing it. This prevents issues with chain reorganizations — if the block is orphaned, the coinbase reward should not have been spendable.

Regular Transactions

After the coinbase, the remaining transactions are standard Bitcoin transactions. Each transaction contains:

• Version (4 bytes)
• Marker and Flag (2 bytes, SegWit only: 0x0001)
• Input count (varint)
• Inputs (variable): each with previous txid, output index, scriptsig, and sequence number
• Output count (varint)
• Outputs (variable): each with value (8 bytes, in satoshis) and scriptpubkey
• Witness data (variable, SegWit only)
• Locktime (4 bytes)

Miners select transactions from their mempool to include in the block, typically prioritizing by fee rate (satoshis per virtual byte) to maximize revenue. The block must not exceed the weight limit of 4,000,000 weight units.

Witness Data and SegWit

Segregated Witness (SegWit), activated in August 2017, fundamentally changed how transaction data is organized within a block. Prior to SegWit, signature (witness) data was embedded directly in transaction inputs. SegWit moved this data to a separate “witness” structure.

The Witness Commitment

SegWit blocks include a witness commitment in the coinbase transaction. This is an OP_RETURN output containing:

OP_RETURN <0xaa21a9ed> <32-byte witness root hash>

The witness root hash is the Merkle root of a tree constructed from the wtxids (witness transaction IDs) of all transactions in the block. The coinbase’s wtxid is defined as 32 bytes of zeros.

This creates two parallel Merkle trees within each block:

1. Transaction Merkle tree (in the header): Built from txids, which do not include witness data
2. Witness Merkle tree (in the coinbase): Built from wtxids, which include witness data

This dual-tree structure is what enables backward compatibility — old nodes validate the transaction Merkle tree (which they understand) while new nodes additionally validate the witness Merkle tree.

Transaction ID vs. Witness Transaction ID

• txid: SHA-256d hash of the transaction serialized WITHOUT witness data
• wtxid: SHA-256d hash of the transaction serialized WITH witness data

For non-SegWit transactions, txid and wtxid are identical. For SegWit transactions, they differ because the witness data is included only in the wtxid calculation.

This separation solved the transaction malleability problem: since the txid does not include signature data, third parties cannot alter the txid by modifying the signature. This was a prerequisite for reliable payment channel construction (Lightning Network).

Block Size vs. Block Weight

Before SegWit, Bitcoin enforced a hard 1 MB (1,000,000 byte) limit on block size. This simple limit was the source of intense debate during the “Blocksize War” of 2015-2017.

SegWit replaced the byte-based size limit with a weight-based system:

Block Weight = (Non-witness data × 4) + (Witness data × 1)

The maximum block weight is 4,000,000 weight units (4 MWU).

This formula gives witness data a 75% discount compared to non-witness data. The rationale:

• Non-witness data (inputs, outputs, amounts) must be stored permanently in the UTXO set and is more expensive for nodes to process
• Witness data (signatures) is only needed for initial validation and can be pruned afterward

In practice, this means:

• A block containing only legacy (non-SegWit) transactions has an effective maximum size of 1 MB (1,000,000 bytes × 4 = 4,000,000 weight units)
• A block with 100% SegWit transactions can be up to approximately 4 MB in raw size, though typical blocks are 1.5-2.5 MB
• The theoretical maximum is a block with a single transaction containing almost entirely witness data, approaching 4 MB — but this is an unrealistic edge case

The largest block mined as of early 2026 was approximately 3.96 MB (block 774,628 in February 2023), which contained a single Ordinals inscription consuming nearly the entire witness space.

Virtual Size (vsize)

For fee calculation purposes, Bitcoin uses virtual size (vsize), measured in virtual bytes (vbytes):

vsize = weight / 4 (rounded up)

Fee rate is expressed as satoshis per vbyte (sat/vB). A transaction with a weight of 600 weight units has a vsize of 150 vbytes. At a fee rate of 20 sat/vB, its fee would be 3,000 satoshis.

Compact Blocks (BIP-152)

In 2016, BIP-152 introduced compact block relay, dramatically reducing the bandwidth required to propagate new blocks across the network. Without compact blocks, a node receiving a new block must download the entire block data, including all transactions — most of which the node has already seen in its mempool.

Compact blocks work by:

1. The sending node transmits a compact block message containing the block header, a list of short transaction IDs (6-byte truncated hashes), and the coinbase transaction
2. The receiving node matches the short IDs against transactions in its mempool
3. For any transactions the receiver is missing, it requests the full transaction data
4. The receiver reconstructs the full block from its mempool transactions plus any requested missing transactions

In practice, because most transactions in a new block are already in the receiving node’s mempool, compact blocks reduce block relay bandwidth by approximately 90%. A 2 MB block that would normally require transmitting 2 MB of data can be conveyed in roughly 20 KB — just the header, short IDs, and coinbase.

BIP-152 defines two modes:

• Low-bandwidth mode: The receiver explicitly requests a compact block after receiving a standard block header announcement
• High-bandwidth mode: The sender proactively transmits compact blocks without waiting for a request, reducing latency at the cost of occasional duplicate data

Block Serialization Format

The complete serialization of a block for network transmission follows this structure:

[4 bytes]  Magic number (0xF9BEB4D9 for mainnet)
[4 bytes]  Block size (total size of following data)
[80 bytes] Block header
[varint]   Transaction count
[variable] Transaction 1 (coinbase)
[variable] Transaction 2
...
[variable] Transaction N

The magic number identifies the network:

• 0xF9BEB4D9: Mainnet
• 0x0709110B: Testnet3
• 0xFABFB5DA: Regtest

This format is used for both network transmission and on-disk storage in the blocks/blk*.dat files of Bitcoin Core’s data directory.

The Block as an Economic Object

Beyond its technical structure, a block represents an economic reality. The miner who produces a block is making economic decisions: which transactions to include (fee maximization), how much computational work to invest (energy cost vs. expected reward), and how to structure the coinbase outputs (immediate spending vs. holding).

The proof-of-work embedded in the block header is not just a technical mechanism — it is an unforgeable record of energy expenditure. The nonce that produces a valid hash below the target represents billions of hash computations, each consuming real electricity. This energy cost is what gives Bitcoin’s immutability its physical grounding: reversing a confirmed transaction requires re-expending all the energy used to mine every subsequent block.

Every block is a chapter in an append-only ledger that has been growing continuously since January 3, 2009. The 80-byte header — smaller than a tweet — carries the weight of the entire chain’s security. Understanding its structure is understanding the foundation of trustless digital money.