Reading Bitcoin Block Headers

What is a Block Header?

A Bitcoin block header is an 80-byte data structure that summarizes an entire block. It contains metadata about the block and cryptographic proofs that link it to the blockchain. The header is what miners hash during proof-of-work mining.

Why Headers Matter

Block headers enable Simplified Payment Verification (SPV). Light clients can download only headers (80 bytes each) instead of full blocks (1-4 MB each), reducing bandwidth by 99.99% while maintaining cryptographic security.

Block Header Structure

The 80-byte header contains exactly 6 fields:

Block header fields (80 bytes total):

1. Version4 bytes

2. Previous Block Hash32 bytes

3. Merkle Root32 bytes

4. Timestamp4 bytes

5. Difficulty Target (Bits)4 bytes

6. Nonce4 bytes

Field 1: Version (4 bytes)

Indicates the block version and signals support for protocol upgrades through version bits (BIP 9).

Example:

20000000 (hex) = 536870912 (decimal)

Version 2 and higher use the top 3 bits for version signaling. The remaining 29 bits can signal support for soft fork proposals.

Common versions: 1 (original), 2 (BIP 34), 4 (BIP 65), 0x20000000 (SegWit signaling)

Field 2: Previous Block Hash (32 bytes)

The double SHA-256 hash of the previous block's header. This creates the blockchain-each block cryptographically links to its predecessor.

Example:

00000000000000000002a7c4c1e48d76c5a37902165a270156b7a8d72728a054

This hash must match the hash of the previous block exactly. If someone tries to modify a historical block, its hash changes, breaking the chain.

Note: Stored in little-endian format in the raw block, but displayed in big-endian (reversed bytes).

Chain Immutability

Modifying any historical block would require recalculating proof-of-work for that block and every subsequent block-computationally infeasible for the entire Bitcoin network's history.

Field 3: Merkle Root (32 bytes)

The root hash of a Merkle tree containing all transactions in the block. This allows efficient verification that a transaction is included in the block.

Example:

7dac2c5666815c17a3b36427de37bb9d2e2c5ccec3f8633eb91a4205cb4c10ff

The Merkle root is computed by repeatedly hashing pairs of transaction IDs until only one hash remains.

Merkle tree construction:

                  Root
                 /    \\
              H(AB)    H(CD)
             /   \\    /   \\
          H(A)  H(B) H(C) H(D)
           |     |    |     |
          TxA  TxB  TxC   TxD

Merkle Proof Efficiency

To prove a transaction is in a block with 2,000 transactions, you only need ~11 hashes (log₂ 2000), not all 2,000 transactions. This is how SPV wallets work.

Field 4: Timestamp (4 bytes)

Unix timestamp (seconds since January 1, 1970) when the miner started hashing the block.

Example:

65a8f2c0 (hex) = 1705570496 (decimal) = Jan 18, 2024 10:34:56 UTC

The timestamp must be:

-Greater than the median of the last 11 blocks
-Less than the network-adjusted time + 2 hours

Timestamp Accuracy

Block timestamps are not perfectly accurate. Miners can manipulate them within the allowed range. Don't rely on block timestamps for precise time measurements.

Field 5: Difficulty Target (4 bytes)

Compact representation of the target threshold that the block hash must be below. This controls mining difficulty and maintains the ~10 minute block time.

Example:

17034219 (hex) = 386,736,665 (decimal)

This compact format encodes a 256-bit target number. The first byte is the exponent, the remaining 3 bytes are the coefficient.

Expanded target:

0000000000000000034219000000000000000000000000000000000000000000

Difficulty adjustment:

Every 2,016 blocks (~2 weeks), Bitcoin recalculates the difficulty target:

New Target = Old Target × (Actual Time / Expected Time) Expected Time = 2,016 blocks × 10 minutes = 20,160 minutes

Field 6: Nonce (4 bytes)

A 32-bit number that miners increment while searching for a valid block hash. This is the "proof" in proof-of-work.

Example:

1a0e7b23 (hex) = 437,813,027 (decimal)

Miners try billions of nonces per second, searching for one that produces a hash below the target.

Mining process:

1.Set nonce = 0
2.Hash the 80-byte header with double SHA-256
3.If hash < target, block is valid! Otherwise...
4.Increment nonce and repeat

Extra Nonce Space

Modern mining exhausts all 4 billion nonce values in seconds. Miners use the coinbase transaction (extra nonce field) and timestamp to create additional search space.

Computing the Block Hash

The block hash is the double SHA-256 of the 80-byte header. This hash must be below the difficulty target.

Hash calculation:

1. Serialize header (80 bytes in little-endian format) 2. SHA-256(header) 3. SHA-256(result from step 2) 4. Reverse bytes (little-endian to big-endian for display)

Example: Block #800000

Raw header (hex):

00000020a054...

First SHA-256:

8f3c2d1...

Second SHA-256:

54a02827...

Reversed (block hash):

00000000000000000002a7c4c1e48d76c5a37902165a270156b7a8d72728a054

Reading a Real Block Header

Let's decode Block #800000 (mined July 14, 2023):

Block #800000 header breakdown:

Version:

20000000 = 536870912 (SegWit signaling)

Previous Block Hash:

00000000000000000001c792a5ea06424db77bf1c8e1c9c6e0d78e3c8c8c8c8c

Merkle Root:

7dac2c5666815c17a3b36427de37bb9d2e2c5ccec3f8633eb91a4205cb4c10ff

Timestamp:

64b0f6c0 = 1689292480 = July 14, 2023 00:08:00 UTC

Difficulty Target:

17053894 = ~53.9 trillion hashes required

Nonce:

1a0e7b23 = 437,813,027

Block Header Chain

Each block header links to the previous one, creating an immutable chain secured by cumulative proof-of-work.

Chain structure:

Block #799998
  Hash: abc123...
  ↓
Block #799999
  Previous: abc123...
  Hash: def456...
  ↓
Block #800000
  Previous: def456...
  Hash: ghi789...

Modifying Block #799999 would change its hash, breaking the link to Block #800000. You'd need to recalculate proof-of-work for all subsequent blocks-impossible to catch up with the network.

SPV (Simplified Payment Verification)

Light clients download only block headers to verify transactions without storing the entire blockchain.

SPV Verification Process

1.Download all block headers (~80 MB for 800,000 blocks)
2.Verify each header's proof-of-work and chain linkage
3.Request Merkle proof for your transaction
4.Verify the Merkle proof against the header's Merkle root
5.Count confirmations (blocks built on top)

Storage Comparison

Full node: ~500 GB (entire blockchain)
SPV client: ~80 MB (headers only)
Reduction: 99.98% less storage while maintaining cryptographic security

Try It Yourself

Use our tools to explore Bitcoin block headers:

Blockchain Explorer

Look up real blocks and examine their headers. See how each field contributes to blockchain security.

Try Blockchain Explorer →

Hash Calculator

Hash block headers with double SHA-256 to verify proof-of-work yourself.

Try Hash Calculator →

The Bottom Line

Bitcoin block headers are elegant in their simplicity-just 80 bytes containing everything needed to verify blockchain integrity. Through hash functions and proof-of-work, these headers create an immutable record that anyone can verify independently. Understanding block headers is key to understanding how Bitcoin achieves decentralized consensus without trusted parties.

Reading Bitcoin Block Headers

What is a Block Header?

Block Header Structure

Field 1: Version (4 bytes)

Field 2: Previous Block Hash (32 bytes)

Field 3: Merkle Root (32 bytes)

Field 4: Timestamp (4 bytes)

Field 5: Difficulty Target (4 bytes)

Field 6: Nonce (4 bytes)

Computing the Block Hash

Example: Block #800000

Reading a Real Block Header

Block Header Chain

SPV (Simplified Payment Verification)

SPV Verification Process

Try It Yourself

Blockchain Explorer

Hash Calculator

The Bottom Line

Official Resources

Bitcoin Documentation

Hash Standards

Related Guides