Read the chain byte by byte
A ten-lesson course built on The Bitcoin Museum. Each lesson pairs real on-chain artifacts with a hands-on hex exercise and a command you run against your own full node. No API keys, no trust, no hand-waving — just bytes and the opcodes that read them.
Every claim in the museum is a byte sequence a full node will return when you ask for the right block. This course teaches you to ask, decode, and check for yourself. You supply the node (or any block explorer's raw-hex view); the course supplies the map.
The arc runs from the outside in: read a whole block, then the miner's own words, then arbitrary data smuggled into outputs and witnesses, then coins that can never move — and finally, prove all of it with the museum's own verifier.
Three museum entries anchor this lesson. Open each in the museum to see its verify fields, then come back:
Every Bitcoin block starts with an 80-byte header — a fixed-size record with exactly six fields. That header is what miners hash twice with SHA-256; its double-hash is the block hash. Everything else in a block (the transactions) hangs off the header through a single field, the merkle root. Learn to read these 80 bytes and you can read the skeleton of any block ever mined.
The six fields, in order on the wire, are: version (4 bytes), previous block hash (32 bytes), merkle root (32 bytes), time (4 bytes), bits (4 bytes), and nonce (4 bytes). All the multi-byte integers are little-endian, and the two hashes are stored byte-reversed from how you normally read them. That reversal is the single most common tripwire for beginners, so we make it explicit below.
Here is the complete raw header of block 0, exactly as getblockheader <hash> false returns it — 80 bytes, 160 hex characters:
01000000 00000000000000000000000000000000 00000000000000000000000000000000 3ba3edfd7a7b12b27ac72c3e67768f61 7fc81bc3888a51323a9fb8aa4b1e5e4a 29ab5f49 ffff001d 1dac2b7c
Now walk it field by field. The hex on each card is the raw little-endian bytes; the meaning is what those bytes decode to:
01000000 reads as 1. Genesis used block version 1. (Reverse the bytes: 00 00 00 01 = 1.)4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b — which is also the coinbase transaction id. That is not a coincidence: block 0 has exactly one transaction, and the merkle root of a single leaf is that leaf's hash.0x495fab29 = 1231006505 = 2009-01-03 18:15:05 UTC. Compare that date to the headline Satoshi buried in this same block's coinbase — The Times, 03/Jan/2009. The timestamp and the newspaper agree to the day. That is the point of the Chancellor message: an unforgeable proof the block is no older than that morning's paper.1d00ffff — the difficulty-1 target, the easiest target Bitcoin allows. It stayed at exactly this value for the first 32,255 blocks (see The Protocol Woke Up) until the network's first difficulty adjustment.0x7c2bac1d = 2083236893. This is the number Satoshi's miner ground through until the header's double-SHA-256 fell below the target. It is the one field a miner is free to change; everything else is fixed by consensus and the transactions.Past the 80-byte header comes a transaction count, then the transactions themselves. Block 0 holds exactly one transaction — the coinbase, the transaction that mints the block reward. It sits at index 0 of every block; there is always exactly one and it always comes first.
The genesis coinbase pays a 50 BTC reward, and it is the most famous unspendable output in Bitcoin. Bitcoin Core treats the genesis transaction specially: it is never added to the UTXO set, so those 50 coins can never be moved — not by anyone, not even Satoshi. (We return to consensus-unspendable coins in Lesson 9.)
Two commands reproduce everything above on your own node. No txindex is required — getblock at verbosity 2 returns every transaction in the block fully decoded:
# 1. Get the genesis block hash bitcoin-cli getblockhash 0 # -> 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f # 2. Dump the whole block, every tx decoded (no txindex needed) bitcoin-cli getblock 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f 2 # 3. Get the raw 80-byte header to decode the fields by hand bitcoin-cli getblockheader 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f false # -> 010000000000...29ab5f49ffff001d1dac2b7c (exactly 160 hex chars = 80 bytes)
That block hash is the chancellor artifact's verify field, verbatim. In the verbosity-2 output, confirm for yourself: tx has length 1, tx[0].vout[0].value is 50, and merkleroot equals tx[0].txid. Then take the raw header from command 3 and slice it into 4 + 32 + 32 + 4 + 4 + 4 byte fields — they will match the cards above exactly.
These lessons assume a Bitcoin full node you can reach with bitcoin-cli. Two forms sidestep a missing txindex: bitcoin-cli getblock <blockhash> 2 returns every transaction in a block fully decoded, and bitcoin-cli getrawtransaction <txid> true <blockhash> decodes a single transaction when you supply its block hash.
No node? Any block explorer's raw-hex or JSON view returns the identical bytes. The header hex for block 0 is the same everywhere — the whole point is that this is consensus data, not one operator's opinion.