Block 0: The Coinbase Bitcoin's Own Code Will Never Spend

Bitcoin's chain begins with a block its own software refuses to treat as ordinary. Block 0 — hash 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f — carries the timestamp 1231006505, which is 3 January 2009 at 18:15:05 UTC. It is 285 bytes, contains exactly one transaction, was mined at difficulty 1 with nBits 486604799 (0x1d00ffff), and has header nonce 2083236893. Its merkle root, 4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b, is simply the hash of that lone coinbase.

What made it famous is 69 bytes of text. The coinbase input script begins 04ffff001d0104455468652054696d6573 in hex: a four-byte push of the difficulty bits (ffff001d), a one-byte push of 0x04, then a push of length 0x45 — 69 bytes — carrying the ASCII string "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks". The headline was real. Times Online ran "Chancellor Alistair Darling on brink of second bailout for banks" on 3 January 2009, bylined Francis Elliott and Gary Duncan, opening: "Alistair Darling has been forced to consider a second bailout for banks as the lending drought worsens." Whatever else it was, the string functions as a proof of date: the block cannot have been constructed before that morning's edition.

The block's single output pays 5,000,000,000 satoshis to a pay-to-public-key script, 4104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac. Hashed the conventional way, that key renders as 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa.

Those 50 coins have never been spendable, and the reason is prosaic rather than mystical. Bitcoin Core's source, at the function that constructs block 0, still carries the explanatory note: "Build the genesis block. Note that the output of its generation transaction cannot be spent since it did not originally exist in the database." The original implementation hard-coded the genesis block and skipped connecting its transaction, so the coinbase output was never inserted into the UTXO set. No node holds an entry against which a spend could be validated. The Bitcoin Wiki attributes this to "a quirk in the way that the genesis block is expressed in the code" and is candid about intent: "It is not known if this was done intentionally or accidentally."

The restriction attaches to that one output, not to the address. Outputs later sent to 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa enter the UTXO set normally and carry no special constraint; the key itself has no protocol-level disability.

Modern Bitcoin Core does not merely tolerate the anomaly — it accounts for it. The gettxoutsetinfo RPC exposes an "unspendables" breakdown whose genesis_block field is documented as "The unspendable amount of the Genesis block subsidy", alongside bip30, "Transactions overridden by duplicates (no longer possible with BIP30)". Bitcoin's issuance schedule therefore overshoots its realisable supply by this subsidy.

One further detail is routinely garbled. Block 1 (00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048) is timestamped 1231469665 — 9 January 2009 at 02:54:25 UTC. The interval is 463,160 seconds: five days, eight hours, thirty-nine minutes and twenty seconds. The widely repeated "six days" — the Bitcoin Wiki says "a full 6 days" — overstates what the two headers actually record.