The Bitcoin whitepaper: which version is which

The four known versions

Dates are the files' own where we hold them; the evidence below does not depend on them.

                        bytes     sha256          /CreationDate            /ModDate
the re-save           188,867   f5aa8f4b…   D:20081003134958-07'00'  D:20240330175340+10'00'
the genuine draft     183,697   427c63b3…   D:20081003134958-07'00'  (none)

Identify any copy in ten seconds

Six tests, all plain text searches. Four of them come from Satoshi's own words in dated records rather than from any file — which is why they can identify even the versions nobody has. The August 2008 column is empty on purpose — that version is lost, and those cells are what a surfacing copy would have to fill in. The 11 November column was empty until its analysis became available; the entries below now come from Appendix PM3, not from the file, which is still in no public hands.

Verify it yourself

Python 3, standard library. No API key, no login, no node required.

1 · Carve the canonical paper out of the block chain

It was embedded in mainnet transaction 54e48e5f… across 945 bare-multisig outputs whose “public keys” are file bytes.

python verify/whitepaper_from_chain.py out.pdf

block   230009        2013-04-06 20:28:10 UTC
carved  184,292 bytes  %PDF-1.4 … %%EOF
sha256  b1674191a88ec5cdd733e4240a81803105dc412d6c6708d53ab94fc248f4f553   matches

Proof-of-work cannot be backdated. This pins the canonical text to April 2013 independently of bitcoin.org, of the Internet Archive, and of us. It says nothing about 2008 and is not offered as if it did.

2 · Compare the two surviving files structurally

python verify/pdf_structure.py canonical.pdf draft.pdf

                        canonical      draft
PDF version              %PDF-1.4    %PDF-1.4
linearized                     no          no
/ObjStm  (PDF 1.5+)             0           0
/XRef    (PDF 1.5+)             0           0
/ID[0] == /ID[1]     never re-saved  never re-saved
embedded subset fonts           7           7
pages                           9           8

3 · Compare the embedded font programs — the deepest test

OpenOffice embeds a subset of each font containing only the glyphs the document uses. Two exports of the same document from the same machine share byte-identical subsets wherever the text did not change.

python verify/pdf_fonts.py canonical.pdf draft.pdf

BAAAAA+CenturySchoolbook-Bold     29,212   29,212   IDENTICAL
CAAAAA+TimesNewRomanPSMT          60,572   60,572   differ
DAAAAA+TimesNewRomanPS-BoldMT     25,632   25,632   IDENTICAL
EAAAAA+ArialMT                    38,580   38,580   IDENTICAL
FAAAAA+TimesNewRomanPS-ItalicMT   37,812   37,812   IDENTICAL
GAAAAA+OpenSymbol                  2,232    2,232   IDENTICAL
HAAAAA+CourierNewPSMT             36,020   36,020   IDENTICAL

byte-identical: 6 of 7

The one that differs is the body text font, and it differs only in glyf, hmtx and loca — which glyphs are in the subset — not in cmap, cvt, fpgm, maxp, name, post or prep. Both carry the same source-font creation stamp of 1990-08-06 13:14:42.

That is the same font files, on the same machine, subsetted by the same software — with different glyphs in the body because the body text changed. To fake it you would need not merely OpenOffice 2.4 but the same physical font files, and six of your subsets would have to hash identically to the file you were imitating.

How the October draft is dated — without trusting the file

A backdated clock can write any creation date. The dating below never uses one.

after    Wei Dai's reply to the 22 Aug 2008 email   — holds a fact Satoshi lacked
before   9 Nov 2008                                 — lacks a paragraph he hadn't written
         the file's own date, 3 Oct 2008, sits inside and does none of the work

A forger cannot put a citation into a document before its author learned it, nor remove a paragraph he had not yet written. Neither is reachable with a backdated clock.

Where the October draft came from

It did not appear from nowhere in 2020. Its history is on the same mailing list that carried the announcement.

So the hash sits in two independent third-party records from early 2015, five years before the archive.org copy existed, and is confirmed by a participant from 2008. And the content dating agrees with the custody claim without either knowing about the other: he said early November 2008; the absent fee paragraph independently says before 9 November 2008.

Recorded for completeness: in 2015 he gives the file's local date as 2 November 2008; in 2017 he writes “received here 2008 November 8”. Six days apart. Both precede the fee proposal, so the dating is unaffected — but the two statements are not identical.

What a court found

COPA v Wright, [2024] EWHC 1198 (Ch), Mr Justice Mellor, 20 May 2024 — 1,698 paragraphs, on expert evidence tested by cross-examination.

So the canonical file's identity is attested by three independent classes at once, agreeing to the second and to the byte: the PDF's own /CreationDate; bitcoin.org's own filesystem, recovered as X-Archive-Orig-Last-Modified: Tue, 24 Mar 2009 17:33:15 GMT; and a High Court expert's report on the copy the court itself used as its control. A self-claim, a web server the author did not run, and an expert cross-examined on his work — all naming the same instant and the same bytes.

The judgment also records that OpenOffice 2.4.0 was released on 26 March 2008 (¶271.1) — a floor on any document claiming that toolchain — and states the forgery method plainly (¶123): a file could be made “by downloading and running that software on a computer (or virtual computer) with a backdated clock.” Which is precisely why the dating above uses content rather than metadata.

The fourth version, and when transaction fees entered the paper

The 11 November 2008 version is in no public hands. But Appendix PM3 to Patrick Madden's First Expert Report analyses it in detail, and that analysis settles two things this page could not previously answer.

BWP-NB1   MD5    3e5e11e1e3208d2829e887fb1c86bd05
          SHA256 e6cc7c952c688b234f9872c3e2f50060ae6556fd27925cba503c6460048e50a9
          created  11 Nov 2008 08:00:34 at UTC−08:00     Writer / OpenOffice.org 2.4 / PDF 1.4
          trailer  /ID <693BFE527899A65C197B4CD42561A6C4> <693BFE527899A65C197B4CD42561A6C4>
                   startxref 182801  →  roughly 184,300 bytes

“The incentive is also funded with transaction fees”
“The output value of every transaction is equal to the input value minus a transaction fee”
“and the incentive is increased by the total transaction fees in the block”

 3 Oct 2008   no transaction fees in the paper
 9 Nov 2008   Satoshi proposes transaction fees on the mailing list
11 Nov 2008   the fee text is in the paper — first wording        ← two days later
24 Mar 2009   the same block reworded to the form everyone knows

Provenance and limits. These figures come from Appendix PM3 §§41–58, obtained as extracted text from a publicly published dataset of the trial bundle. Before relying on it we ran a control: PM3 quotes internal /ID and /CreationDate values for the two versions we already hold, and both matched our own files exactly — byte-level values the extraction could not have guessed. Madden also records that he could find no other copy of this file anywhere: not in Dr Wright's disclosure, not on archive.org, not on the Wayback Machine's captures of bitcoin.org, and no hit for either hash on the open web. We still do not have the file. What changed is that anyone who finds a candidate can now settle it in one command.

The chronology, with its proofs

Every line carries the record that dates it, and the class of that record. Nothing here rests on repetition or on conventional account.

The announcement's own receipt, and a clock that was blamed wrongly

The paper was announced by an email. That email's arrival was recorded by a server that belonged to neither the sender nor the recipient — and that record is public, though it took a while to find.

• The trace chain is archived, under a different header name. Mailing-list archives normally discard the SMTP receipt chain, and five of them return nothing when searched for Received:. Gmane is a mail-to-news gateway: it renames those headers Original-Received: so they do not collide with NNTP's own path headers. The announcement is gmane.comp.encryption.general article 12588, and it carries the whole chain:

  stamped by	time	what it is
  Date:	2008-10-31 18:10:00 UTC	written by the sending software — self-asserted
  anonymousspeech.com	18:20:18 UTC	the sending provider's own SMTP service
  green.metzdowd.com	18:20:34 UTC	the list server's receipt — a third party's clock
  green.metzdowd.com	1 Nov 23:15:35 UTC	the moderated release to subscribers

  The moderation queue is not a property of this message: across all eighteen of that sender's list messages it runs from 7 minutes to 60 hours, median about 16 hours. The announcement waited 28h55m.
• A widely-repeated puzzle, and the answer is the other machine. Two January 2009 emails appear to have been logged by their recipient's server before the sender's server stamped them — an impossible ordering of about 37.6 minutes, published as unexplained in 2020. With only two machines in view, a difference tells you they disagree and nothing about which one is wrong. A third clock settles it:

  pair	difference	evidence
  anonymousspeech ↔ metzdowd	6–19 seconds	18 messages, 86 days — they agree
  finney.org ↔ metzdowd	36:40–37:33	Jan 2009, from that host's own outbound list mail

  Four messages sent across one evening in August 2008 carry deltas spread by one second. A batching queue's delay depends on when a message was sent; a clock offset does not. So it is a clock — and it is the recipient's, running slow, not the sender's running fast. The offset also moves (≈25 min in Feb 2008, ≈90 min in Aug 2008, ≈37 min in Jan 2009), so it is only meaningful quoted with a date.

What this does not do. A list fans one message out and copies the existing relay lines verbatim into every envelope, so extra copies are tamper-evidence, not extra witnesses — the arrival time rests on the list operator's clock. And none of these clocks belongs to a person: 124.217.253.42 is a remailer's relay used by every customer of that service, so its +0800 offset is a server setting and has never been evidence of anybody's timezone. This dates a document. It identifies nobody.

What was searched, and is not there

The part that makes the rest usable. These are searched negatives, not untried routes — recorded so nobody repeats them.

• The 2008 bytes — on six independent archives. No capture, download or published hash of bitcoin.org/bitcoin.pdf from 2008 exists anywhere. This is now established against six instruments, not one:

  archive	earliest record of that URL
  Internet Archive	2010-07-04 — 499 CDX rows; two real payloads ever, neither is the missing file
  Common Crawl	none. CC-MAIN-2008-2009 queried by name — zero captures of the host
  archive.today	2016. Its one 2010-dated row is labelled “archived via web.archive.org” — a re-archive of the row above, not an independent capture
  bitcoin.org's own git	2011-08-31. Two commits ever touch the file; the blob at the first is the canonical, verified by git-blob hash without downloading
  Arquivo.pt (Portugal)	2014-11-27. Host-wide: zero rows before 2010
  Vefsafn.is (Iceland)	2011-08-04

  Three of the six bottom out at the same July 2010 capture — worth knowing, because two archives sharing an earliest date looks like corroboration until one turns out to be quoting the other. The two national archives were checked against that failure mode and pass it: zero exact-second timestamp collisions with the Internet Archive. Both hold the canonical, byte-verified by fetching and hashing.
• Any commitment by Satoshi on the block chain. He knew exactly how — on 9 December 2010 he wrote out the transaction himself (txout: 0.00 <appid, hash> OP_CHECKSIG) and endorsed Hal Finney's simpler method of converting a file's hash to an address and paying it. He used neither. Every on-chain channel has been scanned across his entire active era, for all known versions, in both byte orders, under MD5 / SHA-1 / SHA-256 / double-SHA-256 / HASH160:

  channel	scope	result
  coinbase scriptSigs	whole chain	nothing
  non-coinbase scripts, 2009	by script type	nothing
  hash-to-address (Finney's method)	whole chain	two — both third parties, 2013 and 2014
  output scripts (Satoshi's own method)	blocks 0–150,000	nothing
  input scripts	blocks 0–150,000	nothing

  The two hits are both derived from the canonical paper and both are later third-party acts: a 2013 bulk send of 83 one-satoshi outputs, and a 2014 bot that stamped 100 files in eight weeks. Nothing at all for the 11 November version — which could be tested for without holding a byte of it, since its hash is published in the court record. If anyone had held that file and wanted to prove it, this was the cheap and publicly-endorsed way, and it cost one cent. Every negative above has a passing control behind it; an empty result and a broken query are indistinguishable without one.
• The August 2008 draft. Even a successful capture would not have saved it — that URL was a file-host landing page, not the file. Fetching an actually-archived neighbouring page from the same host in 2009 shows what such a capture preserves: a filename, a byte size, a download count, and no payload. The archive could only ever have recorded a description of the draft. Its link — upload.ae/file/6157/ecash-pdf.html — has 20 Wayback captures, every one a 404, 302 or 406, earliest 2020: already dead when first crawled. The three obvious holders (Wei Dai, Adam Back, Gregory Maxwell) were asked years ago and do not have copies; Hal Finney was asked and died in August 2014.
• The December 2008 SourceForge file. Replaced on 2009-03-24. Its size was never captured — there is a Wayback gap for that project from January to September 2009, and the file-detail page is the only page carrying a size. Not recoverable by machine — and it was downloaded once, see below.
• The cypherpunks cross-post. The announcement was forwarded to cypherpunks@al-qaeda.net on 1 Nov 2008 — one of several independent relays of the cypherpunks mailing list, the domain being its operator's choice and unrelated to its subject matter. That node ran 2005–2013 without public archives; the surviving cypherpunks archives cover the 1990s and 2013 onward. The second list it was cross-posted to is an empty stub — one subscribe confirmation.
• The COPA expert reports (Madden, Rosendahl) are referenced by exhibit number throughout the judgment but are not published. The judgment quotes them extensively; that is what exists publicly.

How these archives actually behave

Every negative on this page depends on an instrument doing what it is assumed to do. Three of them do not, in ways that silently manufacture wrong answers. Recorded because anyone re-running this work will hit them.

• A wildcard plus a match-type is a literal asterisk. Sending a CDX query both a trailing * and matchType=prefix makes it search for a URL containing an asterisk. It matches nothing and returns an empty list — indistinguishable from “never captured”. A sweep of ours reported zero captures for one of the most heavily archived pages on the web until a control pattern caught it.
• Both major indexes are keyed host-first. The Wayback CDX index and Common Crawl's public index run the same software and key URLs by host. A path-only pattern such as */bitcoin.pdf is therefore not expressible, and returns nothing regardless of what was captured. “Did any host anywhere serve this file” is not an answerable question on either — it needs a columnar index where the URL path is a queryable column. The workable substitute is to enumerate candidate URLs from documents that name them, and query each one.
• Common Crawl's ARC-era digest includes the record separator. Its index reports a base32 SHA-1 that is computed over the response body plus a trailing newline, so it never equals a clean hash of the file. Comparing the two produces a guaranteed mismatch on every record. A 2012 capture of bitcoin.org/bitcoin.pdf carries a digest matching nothing known; fetching the record, stripping one byte, and hashing gives b1674191… — the canonical file. Any cross-system hash comparison must be calibrated against a file you already hold.
• And one that is simply gone. CiteSeerX — an autonomous crawler that stored PDFs from the open web with crawl metadata, and the obvious place to look for a dated early copy — is decommissioned. citeseerx.ist.psu.edu now redirects to an Internet Archive snapshot, and its search endpoints answer nothing.

A 404 is not always an absence. On Common Crawl's index a 404 means “no rows for that URL”, not “no index” — the 2008–2009 collection answers normally for google.com and wikipedia.org while returning 404 for bitcoin.org. Before reading a 404 as evidence of absence, prove the endpoint can return anything at all.

How many people downloaded it

SourceForge still publishes its own download statistics, month by month, back to the project's registration. No key, no login.

https://sourceforge.net/projects/bitcoin/files/stats/json?start_date=2008-11-09&end_date=2009-06-30

   2008-11         0
   2008-12         1     <- the whitepaper was the ONLY file in the project that month
   2009-01       141     <- v0.1 released 8 Jan 2009
   2009-02        49
   2009-03        59

Satoshi uploaded the paper to SourceForge on 8/9 December 2008 and the software on 8 January 2009 (COPA v Wright, agreed chronology ¶23.5 and ¶23.7). So in December 2008 the project held exactly one file — and it was downloaded once.

Checked across four independent query windows; all return 1, and an isolated December query returns total: 1. Reproduce with verify/sourceforge_download_stats.py.

Can any of this ever prove Satoshi wrote it?

No. And that is a fact about the evidence, not a gap in the searching — so it is worth stating precisely rather than leaving as an impression.

Two questions get run together constantly, and they behave completely differently:

Why the second one is closed

To establish authorship by machine you would need a digital signature over the document, made with a key established as the author’s independently of the claim. Three things stand in the way, and the third is the one usually missed.

• No such signature exists. The keys we can call Satoshi’s — by the convention that the genesis coinbase key’s holder is Satoshi — have signed exactly two things, ever: the transaction that paid Hal Finney 10 BTC in block 170, and the one that spent its change in block 181. Both are transaction signatures. A Bitcoin transaction signature covers a hash of the transaction; a message signature covers a hash of the message. For one to double as the other you would need a second-preimage collision in SHA-256 — which is the thing SHA-256 exists to prevent.
• Nobody but the key-holder can create one. That is not a research obstacle. It is what a signature scheme is. Those keys have been dormant since 2011.
• And even a signature would not prove authorship. If the key-holder appeared tomorrow and signed the canonical paper, it would establish one thing: the holder of this key endorses this document. Not who composed it. People sign documents they did not write — that is what signatures are for. Authorship is not a cryptographic property of a document, and no amount of cryptography makes it one.

So the honest ladder looks like this, and the canonical paper sits near the top of what is achievable rather than short of something that was ever available:

The canonical whitepaper is among the best-attested documents of its era. It is not, and cannot become, a verified-authored one. Anyone offering you cryptographic proof that Satoshi wrote a particular file is selling something the mathematics does not contain.

So — is this “the real whitepaper”?

You have to say which one, and then the answer is exact.

As “the paper as it stood when it was announced in October 2008” — the 3 October draft is about as established as a document gets: byte-identical from two unrelated hosts, its hash in two independent 2015 records, confirmed by a participant from the 2008 thread, a forensic control copy in the High Court, sharing six byte-identical font programs and its entire toolchain with the canonical, and bracketed on both sides by evidence that is not its own metadata.

As “the canonical paper, the one bitcoin.org serves” — that question is now closed. Its bytes are in the block chain; its creation instant is confirmed to the second by a web server the author did not run; and a High Court expert publishes its MD5 and SHA256, both matching the file recovered from the chain. Self-claim, server record and adjudicated finding agree completely. There is nothing left to establish about it.

What is not true, and we will not pretend otherwise: no 2008 cryptographic timestamp exists for any version. The earliest recorded hash is January 2015. The early-November download rests on a pseudonymous party's word — corroborated by content, but not anchored. And it is not demonstrated to be the exact bytes behind the 31 October link, only the simplest explanation of every observation.

That residual doubt is not a gap in this research. It is a property of the 2008 record: nobody hashed the file at the time, and no one can retroactively. Anyone claiming cryptographic certainty about an October 2008 document is overstating. What can be done is to state exactly where the line falls — which is what this page is for.