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

Seven tests, all plain-text searches. Four of them come from Satoshi's own words in dated records — the 20 August 2008 email the judgment quotes (¶661) and the 22 August email Wei Dai published — rather than from any file, which is why they can identify even the lost draft. The court-record column is blank on purpose: the file is in no public hands, and what is in evidence about it is not published; its cells are what a surfacing copy would fill in.

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 a transaction on the 2009 Bitcoin chain, 54e48e5f… across 946 bare-multisig outputs (945 carrying three 65-byte pushes, one carrying the 33-byte tail) 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]     not re-saved    not 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 does not use one.

after    Wei Dai's reply to the 22 Aug 2008 email   — holds a fact Satoshi lacked
before   9 Nov 2008                                 — lacks a paragraph they 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 they 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 judgment's own record of the copy the court used as its control (¶320). A self-claim, a web server the author did not run, and a finding in a public judgment — 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 the expert's summary, quoted in the judgment at ¶193, states that a document 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: in the court record, not in public hands

The judgment in COPA v Wright records (¶271.9) that Nicholas Bohm, a retired solicitor who corresponded with Satoshi shortly after the January 2009 release, provided a version of the whitepaper he had downloaded in January 2009, which an expert witness (Mr Madden, ¶271.9) authenticated and which was used in the evidence as a control copy. That is what the public record states, and it is what this page states.

 3 Oct 2008   no transaction fees in the paper
 9 Nov 2008   Satoshi proposes transaction fees on the mailing list
 Jan 2009     a version in the court record — its text is not published
24 Mar 2009   the fee text in the form everyone knows

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 is not 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 in total, 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 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. The method was known to them — on 9 December 2010 they wrote out the transaction themselves (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. They used neither. Every on-chain channel has been scanned across their 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 for any third version. A holder of one could have proved it this way, cheaply and by Satoshi's own method, without publishing a byte of it. 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 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. No surviving copy is known: the people who received it in 2008 have not produced one, and Hal Finney died in August 2014.
• The December 2008 SourceForge file. Replaced on 2009-03-24. Its size was not 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.
• Court material. This page cites the published judgment, COPA v Wright [2024] EWHC 1198 (Ch), by paragraph, and nothing else from the proceedings: the expert appendices and witness statements it refers to are not published by the court or the parties, and this page does not reproduce, re-host or rely on copies of them in circulation.

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 “not 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 does not equal a clean hash of the file. Comparing the two produces a 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 necessarily 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 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. No message signature from any key attributed to Satoshi is known. The early coinbase keys attributed to Satoshi by convention — an attribution, not a proof — have produced only transaction signatures: block 9’s key spending to Hal Finney in block 170, for example, and the spends that followed. Those 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.
• 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.

The standards available, and where the canonical file stands against each — near the top of what is achievable rather than short of something that was available:

The canonical whitepaper is among the best-attested documents of its era. It is not a verified-authored one, and the three points above are why no signature would make it so. Cryptographic proof that Satoshi wrote a particular file is not something the mathematics can supply.

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 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 established: 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.