Bitcoin Genesis Block Raw Data: Every Byte Decoded and Verified
A complete field-by-field decode of Bitcoin's genesis block — the 80-byte header, the coinbase transaction hex, the embedded message, and a script you can run to verify the merkle root and block hash yourself.
The Bitcoin genesis block is 285 bytes. This guide decodes all of them: what each field means, how the byte ordering works, and how to reproduce the block hash from scratch so you are trusting arithmetic rather than a block explorer.
Every value below was verified two ways while writing this page — by recomputing the hashes locally from the raw bytes, and by cross-checking against a public node's API. The verification script is included so you can repeat it.
The Complete Raw Block
All 285 bytes, hex-encoded:
0100000000000000000000000000000000000000000000000000000000000000
000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa
4b1e5e4a29ab5f49ffff001d1dac2b7c01010000000100000000000000000000
00000000000000000000000000000000000000000000ffffffff4d04ffff001d
0104455468652054696d65732030332f4a616e2f32303039204368616e63656c
6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f75742066
6f722062616e6b73ffffffff0100f2052a01000000434104678afdb0fe554827
1967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4
f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000The line breaks are for display only; concatenate them to get the byte stream. It splits into three parts: an 80-byte header, a one-byte transaction count, and a 204-byte coinbase transaction.
Part 1: The 80-Byte Header
| Field | Raw hex | Decoded | Notes |
|---|---|---|---|
| Version | 01000000 | 1 | Little-endian 4-byte integer |
| Previous block hash | 32 bytes of 00 | none | The chain root has no parent |
| Merkle root | 3ba3edfd...4b1e5e4a | see below | Stored in internal byte order |
| Timestamp | 29ab5f49 | 1231006505 | 3 January 2009, 18:15:05 UTC |
| Bits (difficulty target) | ffff001d | 0x1d00ffff | Decimal 486604799, difficulty 1 |
| Nonce | 1dac2b7c | 2083236893 | The value that satisfied the target |
Three things trip people up here.
Byte order. Integers in the header are little-endian. The timestamp bytes 29ab5f49 read as 0x495fab29, which is 1231006505 in decimal. Hashes are stored in internal byte order and displayed reversed, which is why the merkle root begins with 3ba3edfd in the raw block but is printed as 4a5e1e4b... everywhere else. Both are the same 32 bytes.
Compact target encoding. The bits field 0x1d00ffff is not a number to compare against; it is a compact float. The first byte, 0x1d, is an exponent; the remaining three, 0x00ffff, are the coefficient. Expanded, the target is:
00000000ffff0000000000000000000000000000000000000000000000000000Any header hash numerically below that value is valid. This is difficulty 1, the easiest target Bitcoin allows.
The extra zeros. Difficulty 1 requires the hash to start with 8 hexadecimal zeros. The genesis hash starts with 10:
000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26fIt is roughly 256 times better than it needed to be. The usual reading is that Satoshi mined many candidate blocks over some period and shipped a good-looking one, which is consistent with the six-day gap before block 1.
Part 2: The Coinbase Transaction
One byte, 01, records the transaction count. Then 204 bytes of transaction:
01000000 version = 1
01 input count = 1
0000...0000 (32 bytes) previous txid: null
ffffffff previous output index: 0xffffffff
4d scriptSig length = 77 bytes
04 ffff001d push 4 bytes: the bits value
01 04 push 1 byte: 0x04
45 <69 bytes> push 69 bytes: the message
ffffffff sequence
01 output count = 1
00f2052a01000000 value = 5000000000 satoshi = 50 BTC
43 scriptPubKey length = 67 bytes
41 <65-byte public key> ac push pubkey, then OP_CHECKSIG
00000000 locktime = 0The null previous txid and the 0xffffffff output index are what make a transaction a coinbase — it has no source, it creates value.
The output is pay-to-public-key, the original 2009 output type: a raw 65-byte uncompressed public key followed by OP_CHECKSIG. There is no address in the block at all. The familiar address 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa is derived from that public key by hashing it with SHA-256 then RIPEMD-160 and base58check-encoding the result with version byte 0x00. Running that derivation on the block's public key reproduces the address exactly.
Part 3: The Message
The 69-byte push in the scriptSig is ASCII:
5468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72
206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f7220
62616e6b73Decoded, it reads: The Times 03/Jan/2009 Chancellor on brink of second bailout for banks.
This is the headline of that day's front page of The Times of London, referring to the UK Chancellor's plans for a further bank rescue. The newspaper page itself, its photography, and the article text are the copyright of Times Newspapers; what is embedded in the block is only the 69-character headline string. We describe the source here rather than reproduce it — the archived article is the place to read it.
Technically, the message serves as a proof of earliest possible date. A block containing a 3 January headline cannot have been created before 3 January. It is the same trick Haber and Stornetta used when they published hashes in a newspaper — running in the opposite direction.
Verify It Yourself
Save this as verify-genesis.mjs and run it with Node. It rebuilds the coinbase transaction and header from their parts and hashes them.
import { createHash } from "crypto";
const dsha = (b) =>
createHash("sha256").update(createHash("sha256").update(b).digest()).digest();
const display = (b) => Buffer.from(b).reverse().toString("hex");
const message = "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks";
const messageHex = Buffer.from(message, "ascii").toString("hex");
const scriptSig = "04ffff001d" + "0104" + "45" + messageHex;
const coinbaseHex =
"01000000" +
"01" + "0".repeat(64) + "ffffffff" +
(scriptSig.length / 2).toString(16) + scriptSig + "ffffffff" +
"01" + "00f2052a01000000" + "43" +
"41" +
"04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb" +
"649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f" +
"ac" +
"00000000";
const txid = dsha(Buffer.from(coinbaseHex, "hex"));
console.log("txid / merkle root:", display(txid));
const le32 = (n) => Buffer.from(new Uint8Array(new Uint32Array([n]).buffer)).toString("hex");
const header =
"01000000" + "0".repeat(64) + txid.toString("hex") +
le32(1231006505) + "ffff001d" + le32(2083236893);
console.log("block hash:", display(dsha(Buffer.from(header, "hex"))));Expected output:
txid / merkle root: 4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b
block hash: 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26fIf you run a full node, the equivalent one-liner is:
bitcoin-cli getblock 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f 2Note that the merkle root equals the coinbase txid. With one transaction in the block, the merkle tree is a single leaf, so the root is just that transaction's hash — no pairing, no concatenation.
Why the 50 BTC Cannot Be Spent
The output script is perfectly valid. Anyone holding the corresponding private key could sign for it. The coins are nonetheless unspendable, and the reason is a quirk of the original implementation rather than the script.
Bitcoin's original code handled the genesis block as a special case and never added its coinbase output to the database of spendable outputs, the UTXO set. Every subsequent implementation preserved that behaviour, since changing it would be a consensus-breaking fork. A transaction spending the genesis output would be rejected by every node, because as far as their databases are concerned the output does not exist.
Whether this was an oversight or deliberate is unknown. The practical result is that Bitcoin's first 50 coins are permanently outside the supply, and the address has since accumulated a further stream of small tribute payments — those are ordinary outputs and are technically spendable by whoever holds the key, though none has ever moved.
Two Common Misreadings
"The genesis block was mined on 3 January, so Bitcoin launched that day." The block's timestamp is 3 January 2009 at 18:15:05 UTC, but the software was not released until 8 January, and block 1 was not mined until 9 January 2009 at 02:54:25 UTC — a gap of about 5.4 days. During that window no one but Satoshi was running the network.
"The hash proves Satoshi did enormous work." Difficulty was 1, the minimum. A modern ASIC would find a valid nonce at that target in a fraction of a second. The ten leading zeros indicate a good draw among many attempts on 2009 hardware, not a heroic computation.
Field Reference Summary
| Property | Value |
|---|---|
| Height | 0 |
| Block hash | 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f |
| Merkle root | 4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b |
| Timestamp | 1231006505 — 3 January 2009, 18:15:05 UTC |
| Version | 1 |
| Bits | 0x1d00ffff (486604799), difficulty 1 |
| Nonce | 2083236893 |
| Transactions | 1 |
| Block size | 285 bytes |
| Reward | 50 BTC, unspendable |
| Output address | 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa |
| Next block | 00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048 |
Sources
- Genesis block hex dump — Bitcoin Wiki
- Bitcoin v0.1 source code — the hardcoded block as Satoshi wrote it
- Block chain reference — header field specification
- Bitcoin Core chainparams.cpp — how the block is constructed in current code