The whitepaper is apparently encoded at 54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713, which is an m of n multisig Tx with 947 outputs (just under the scriptsig limit of 20kB!).

Using the Blocktrail Python SDK, I get a list of the outputs as hex using the following Python (2.7) code (NB, the APIKEY, APISECRET parameters are available if required from www.blocktrail.com):

from blocktrail import APIClient
bt_client = APIClient(APIKEY, APISECRET, network='BTC')
txnObj = bt_client.transaction('54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713')
hashes = [(t['script_hex']) for t in (txnObj)['outputs']]   

The resulting list is available here in full and is essentially all pay-to-pubkey-script Txns. An excerpt:


QUESTION: How is this array of hex data parsed into the bitcoin.pdf? Specific Python framed answers would be appreciated!

  • I should add its 945x *? of 3*(?) txns and 2x paytopublickey outputs – Wizard Of Ozzie Feb 9 '15 at 12:41
  • scriptsig limit of 20kB! I was aware of a 10 kB limit, enforced in EvalScript, but what 20 kB limit are you referring to? – Nick ODell Feb 9 '15 at 16:18
  • @NickODell isn't the limit for scripts 20kb? – Wizard Of Ozzie Feb 10 '15 at 6:20

This is a fun little puzzle on the blockchain, basically. First, you need to know a little about pdf's and how they're structured, which you can find here.

Second, you'll note from section 3.4.1 that all pdf's start with this string:


In hex, that is 255044462d. And indeed that is in the very first output in the very first bare multisig pubkey:


I haven't figured out what the first 8 bytes are for (♦edit: e4cf0200067daf13 = 2x 4byte little Endian "checksums", see @WizardOfOzzie comment below), but the rest of the bare multisig keys (everything in between 1 and 3 OP_CHECKMULTISIG in each output -- note the last one is a 1 of 1, so it's 1 OP_CHECKMULTISIG) are pieces of data for the pdf and they are in order. If you can put all the hex digits of the bare multisig keys into a single file (no whitespaces) called "fromblockchain.hex", you can run this very simple program to extract the pdf:

contents = open('fromblockchain.hex').read()
bytes = contents[16:].decode('hex')
f = open("bitcoin.pdf")

This should create a bitcoin.pdf which is the actual satoshi whitepaper. I've tested this and indeed it is the whitepaper. Good to know it's literally in the blockchain.

Alternatively, if you have bitcoind running on your machine, you can run this python script to grab the bitcoin whitepaper:

import subprocess

# raw = full hex of raw Tx using Bitcoin-cli
raw = subprocess.check_output(["bitcoin-cli", "getrawtransaction", "54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713"])

outputs = raw.split("0100000000000000")

pdf = ""
for output in outputs[1:-2]:
    # there are 3 65-byte parts in this that we need
    cur = 6
    pdf += output[cur:cur+130].decode('hex')
    cur += 132
    pdf += output[cur:cur+130].decode('hex')
    cur += 132
    pdf += output[cur:cur+130].decode('hex')

pdf += outputs[-2][6:-4].decode("hex")
f = open("bitcoin.pdf", "wb")

Finally checking checksum

sha256sum bitcoin.pdf
b1674191a88ec5cdd733e4240a81803105dc412d6c6708d53ab94fc248f4f553  bitcoin.pdf
  • Ahh ha! Another fantastic answer! I was trying to get a script like the above working and couldn't parse the hex after 0x5141 and between the 0x41s. What is up with the last two outputs being standard 76a914____88ac? – Wizard Of Ozzie Feb 10 '15 at 6:19
  • Looked to me like the person spent 1 satoshi on each output and wanted the change back for the last one. Not sure about the second to last. – Jimmy Song Feb 10 '15 at 6:31
  • Perhaps the it's a dual purpose: allows output to be collected and the data length can't be padded, since 20 bytes x2 % 8 whereas doing that with 65 bytes is much harder (actually 65x3) – Wizard Of Ozzie Feb 10 '15 at 8:02
  • Did you want to edit the bottom script to add the output at outputs[-2]? The script needs this after the for loop: pdf += outputs[-2][6:-4].decode('hex'). Also open needs to be using open("bitcoin.pdf", 'wb') (binary mode). I'll have to look into multisig more b/c I still fail to see why the rest of the multisigs are pushing 0x41 bytes Vs the last only pushing 0x21 bytes – Wizard Of Ozzie Feb 10 '15 at 10:32
  • 2
    Also, getrawtransaction now takes an optional blockhash argument. So that removes the need for -txindex here. – Sjors Provoost Jan 21 at 13:00

This is a bash command that can also give you the file:

bitcoin-cli getrawtransaction 54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713 0 00000000000000ecbbff6bafb7efa2f7df05b227d5c73dca8f2635af32a2e949  | sed 's/0100000000000000/\n/g' | tail -n +2 | cut -c7-136,139-268,271-400 | tr -d '\n' | cut -c17-368600 | xxd -p -r > bitcoin.pdf

It doesn't need -txindex, but it does need a full node, not pruned. I suppose it's possible to make a variant that works with gettxout that works with pruned nodes, but that's left as an exercise for the reader.

  • 3
    Exercise done by @jb55 :-) seq 0 947 | (while read -r n; do bitcoin-cli gettxout 54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713 $n | jq -r '.scriptPubKey.asm' | awk '{ print $2 $3 $4 }'; done) | tr -d '\n' | cut -c 17-368600 | xxd -r -p > bitcoin.pdf Source: bitcoinhackers.org/@jb55/105595146491662406 – darosior Jan 21 at 22:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.