The genesis block message, byte by byte

SummaryBitcoin's genesis block carries the text "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks". The text is not in the 80-byte block header. It sits in the scriptSig of the block's single coinbase transaction, as 69 ASCII bytes starting at byte 131 of the 285-byte block. The header commits to it through the merkle root, so changing one letter of the headline would change the block's hash.

Most descriptions of block 0 stop at "Satoshi put a newspaper headline in it". This post goes one level down: which bytes, in which field, and how a header that does not contain the text still locks it in place. All the hex below is the real block. I re-hashed it while writing this, and you can do the same in the genesis block decoder.

The header: 80 bytes, no headline

A Bitcoin block header is always 80 bytes, in six fields. Here is block 0's:

01000000                                                          version
0000000000000000000000000000000000000000000000000000000000000000  previous block hash
3ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a  merkle root
29ab5f49                                                          time
ffff001d                                                          bits (target)
1dac2b7c                                                          nonce

The multi-byte numbers are stored little-endian, which is why the nonce 0x7c2bac1d appears in the header as 1d ac 2b 7c.

Hash those 80 bytes with SHA-256 twice, reverse the result for display, and you get the block's ID:

000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f

That is ten leading hex zeros. The target in the bits field only demanded eight, so block 0 cleared its own bar with two zeros to spare.

Notice what is missing. Nothing in those 80 bytes spells "The Times". The header has no free-text field at all.

The coinbase transaction: where the words are

Every block's first transaction is the coinbase, the one that creates the block reward. It has a single input that spends nothing, and because that input spends nothing, its unlocking script (the scriptSig) does not have to unlock anything. The miner can put bytes of their choosing there. That is the only free-text space a miner gets.

Block 0's coinbase transaction is 204 bytes. Its scriptSig is 77 of them:

04 ffff001d                    push 4 bytes: the bits value again
01 04                          push 1 byte: the number 4
45                             push 0x45 = 69 bytes:
5468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72
206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f7220
62616e6b73

Read the last 69 bytes as ASCII and you have it:

54 68 65 is "The". 54 69 6d 65 73 is "Times". The slashes in the date are 2f. There is no terminator and no length beyond the single push byte 45 in front.

The exact position, counting from zero:

• byte 8 of the 77-byte scriptSig,
• byte 50 of the 204-byte transaction (after the version, the input count, the 36-byte null outpoint and the script length),
• byte 131 of the full 285-byte block (after the 80-byte header and a one-byte transaction count).

The rest of the transaction is one output of 50 BTC paid to a public key. That output is famously unspendable: the original software never added the genesis coinbase to its database of spendable outputs.

How 80 bytes seal a sentence they do not contain

The link between the two parts is the merkle root. Hash the 204-byte coinbase transaction twice with SHA-256 and you get its transaction ID. A block with a single transaction uses that ID directly as its merkle root, and those are the 32 bytes at offset 36 of the header.

So the chain of dependence runs like this. The headline is inside the transaction. The transaction's hash is inside the header. The header's hash is the block ID with its ten zeros.

Change "brink" to "edge" and the transaction ID changes completely. The merkle root in the header is now wrong. Put the new root in and the header is a different 80 bytes, whose double SHA-256 is some ordinary-looking number with no run of zeros at the front. To make the altered block valid again, someone would have to redo the proof of work: try nonces until the hash falls under the target once more.

That is the whole mechanism. The header does not store the message. It stores a commitment to it, and proof of work makes the commitment expensive to redo.

What the headline was for

The Times of London ran that headline on 3 January 2009. Satoshi did not annotate the choice inside the block. It is usually read two ways at once: as evidence that the block could not have been made before that date, and as a comment on the bank bailouts of the time. The first reading is the one the bytes can support on their own.

The same layout, reused

The blocks this site strikes copy block 0's structure byte for byte, with a different sentence. The first one my miner produced has this scriptSig:

04 ffff001d  01 04  10  436f6d70616320462047656e65736973   "Compac F Genesis"

Same two leading pushes, then a push of 16 bytes instead of 69. Its header hash is 000000002bfdd443…, eight zeros. Consensus rules cap a coinbase scriptSig at 100 bytes, which is one reason inscriptions here are a single short line.

The difference that matters is where the block lives. Block 0 is the first block of Bitcoin's chain, and every later block builds on it. A struck block is a standalone block. It follows the same format and its proof of work checks the same way, but it is not on Bitcoin's blockchain and no network stores it.

To see every field of block 0 laid out and re-hashed in your browser, use the genesis block decoder. To build and hash a header of your own, there is a block header calculator.

Strike a Block mines one line of your text into a standalone block with the same layout, on a real Bitcoin ASIC. See the tiers.