The Bitcoin whitepaper has lived inside the blockchain since 2013

At 20:28:10 UTC on 6 April 2013, in block 230,009, a single Bitcoin transaction carried the entire Bitcoin whitepaper into the ledger that paper describes. Transaction 54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713 is 198,724 bytes long, spends one input of 0.78305768 BTC, creates 948 outputs, and paid a fee of 0.596175 BTC. That is about 300 satoshis per byte, and 76% of the input value, at a time when ordinary fees were a small fraction of a bitcoin.

The method was blunt and precise. 945 of the outputs are bare 1-of-3 multisig scripts and one more is a 1-of-1, 946 in total, each holding exactly one satoshi. In a normal multisig output those slots hold public keys; here they hold slices of a file — 2,835 slots of 65 bytes and one of 33. Concatenated in order they yield 184,308 bytes opening with a small header: four bytes little-endian giving the file length, 184,292, then four bytes of CRC32. Strip those eight, take the next 184,292, discard eight trailing zero bytes, and the result is a PDF whose SHA-256 is b1674191a88ec5cdd733e4240a81803105dc412d6c6708d53ab94fc248f4f553 — the same length and the same hash as the file served from bitcoin.org today. Node guides such as RaspiBolt ship a one-line pipeline that performs this reconstruction against your own copy of the chain.

Two outputs are not data. One is change. The other is a single satoshi to 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa, the address that received the genesis block's coinbase. That is less of a bespoke gesture than it looks: Ken Shirriff found the same one-satoshi payment to the genesis address in the transactions carrying the uploader and downloader tools used in the same burst, so it appears to be a habit of the toolchain.

Nothing about the design was free. Bare multisig outputs are indistinguishable from spendable ones, so every validating node must carry them indefinitely. Of the 948 outputs, 947 have never been spent; only the change moved. The whitepaper is a resident of the UTXO set, not a prunable footnote.

It was not an isolated stunt. The uploader tool's own transaction had landed three hours earlier, in block 229,991 at 17:17 UTC. Ten minutes after the whitepaper, in block 230,010, the first chunk of the WikiLeaks Cablegate archive appeared; the archive ran to 130 transactions of about 20,000 bytes each, ending in block 230,136 on 7 April, with an index transaction in block 230,203 on 8 April. Shirriff catalogued the whole episode in 2014 and noted that the uploader and downloader code was labelled as Satoshi Nakamoto's work — an attribution he judged probably untrue. The author of the whitepaper transaction has never been identified.

The consequences outlived the week. Bitcoin Core 0.9.0, released 19 March 2014, made OP_RETURN outputs a standard relayed type, which the release notes describe as creating "a provably-prunable output, to avoid data storage schemes — some of which were already deployed — that were storing arbitrary data such as images as forever-unspendable TX outputs, bloating bitcoin's UTXO database." The same notes were direct that storing arbitrary data in the blockchain remained a bad idea and that it was cheaper and more efficient to store non-currency data elsewhere.

More than a decade on, the same trade-off is still being argued: prunable data nodes can forget, versus data lodged in outputs nodes must keep. Bitcoin Stamps deliberately use bare multisig for exactly the reason this transaction did — to resist pruning — and the recent fight over OP_RETURN size limits turns on whether restricting the prunable option pushes data into the UTXO set instead. The document specifying the system turns out to be very difficult to remove from it.