Evidence‑first, executable reconstructions of the earliest Bitcoin — the 15 Nov 2008 pre‑release and the January 2009 released client — built from two hash‑verified archives, with nothing disabled and no chain privileged. Released as candidates: a Bitcoin, not the Bitcoin. Not money.
Bitcoin (2026) — experimental, not money — runs that same January 2009 client on a genesis of its own — its own network, its own signed release, and a chain mined intermittently; the current tip is on the status feed. It is not a reconstruction and not interoperable with the two above. It is the one with a live network and a released client; the two reconstructions above are the laboratory's subject.
New here, or writing about this? In thirty seconds: what this is, and what it is not → · in the repository: five findings by ID, one command →
The January 2009 archive is served under the name bitcoin-0.1.0.rar by the hosts that carry it. The bytes say it is v0.1.1, built 10 January 2009 — two days after v0.1.0 was announced. We inherited that label and repeated it; this note records what the file actually is. The 0.1.0→0.1.1 delta is irc.cpp and serialize.h — networking only — so no genesis, consensus or executed result on this site changes. the six checks →
Its own genesis, its own network, its own signed release — running Satoshi's January 2009 client. Every block after the genesis has been mined by a released client (most inside the laboratory, ten of them — the first at 221–222 — by runs outside it), bound to it before and after by process identity. Sealed findings sets cover the chain block by block; the current tip is on the live status feed. Separate from the two reconstructions; they do not interoperate.
Open Bitcoin →The released January 2009 constitution — COIN=1e8, 50-coin subsidy, 210k halving, 10-minute target — with the full original opcode vocabulary and OP_NOTEQUAL re-opened. Nothing disabled.
Open JAN09-X →November 2008's constitution instead — COIN=1e6, 100-coin subsidy, 100k halving, 15-minute target, and proof-of-work counted in leading zero bits rather than a compact target.
Open NOV08-X →A node serves Bitcoin, and two live anchors serve JAN09-X and NOV08-X. Clone the repo and point a node at any of the three — it syncs and independently re-validates every block.
Read the invitation →Anchor uptime, each chain's tip height, and the most recent blocks — measured live over the peer-to-peer protocol.
See the live status →Rebuild Satoshi's 3 Jan 2009 block from the Times headline and the raw parameters, hashed live in your browser — no server, no install, nothing to trust but SHA-256. Change a character and watch it break.
Open the verifier →Paste raw bytes and re-check them on your device — proof-of-work, the merkle commitment, the script interpreter, ECDSA — run by the node's own Rust validator compiled to WebAssembly. No server; nothing to trust but the bytes.
Open the verifier →Pick an origin and a moment in history; see how far each Bitcoin version stood from it. Distance, not identity.
Open the tracker →Describe any object — a paper, a chain, a token, an amount — and see where it qualifies as a Bitcoin or a satoshi, and where the answer is convention, not fact.
Open the compass →There are two Bitcoin geneses now — January 2009 and August 2026. Same axes, same derivation, no ranking: what differs, what is identical, and what cannot be proved about either.
Compare them →On a pinned period toolchain, Satoshi's unmodified source compiles and runs — from the
sha.cpp hash and the Script interpreter to a full
bitcoin.exe linked from source (i686 · OpenSSL 1.0.2 ·
wxWidgets 2.8 · Berkeley DB · Boost).
Two unmodified 2009 binaries, in isolated VMs, re-derive the genesis and then mine, relay, sustain, and reorganise real blocks — each result verifiable from the raw block bytes.
See the witness →November 2008 hardcodes a genesis too. Its hash re-derives from a 76-byte header — four
shorter than January's — and its coinbase is the bare integer 247422313:
no headline, no proof of time, stamped seven weeks before the whitepaper was public.
v0.1.0 against v0.1.3 of 13 January 2009, the next codebase that survives, file by file. 8 of 26 changed; no consensus rule moved. The archive's provenance is traced to two independent mirrors, and a sha256 recorded for it that neither publishes.
Read the diff →Two independent nodes (Python + Rust), cross‑checked byte‑for‑byte. verify_genesis.py
re‑derives both genesis blocks from source.
The runbooks that build and run each chain, the release‑signing and verification guides, and the scope, evidence and governance notes — the whole written record, listed once.
Open the index →What this is. A research microscope, not a coin. Which live network "is" Bitcoin has no factual answer — only convention; this lab privileges none. The experimental chains are stamped not money: no premine, no sale, no value assigned, no promises. The durable artifact isn't a running node — it's the reproducible recipe, which lets anyone re‑derive the exact genesis with no key and no node to trust.
Verify what you run. Every release tarball is GPG‑signed by
the laboratory release key — fingerprint
B128 526A F85A E4A8 F22B 949F B014 5F74 B78C F1DA.
How to verify →
Post-quantum signing, measured. What a quantum-resistant signature would actually cost a 2009-shaped chain — signature and key sizes cross-checked against FIPS 204/205, sign and verify timings against a measured process-spawn floor, and the transaction arithmetic that follows. Verification cost sits below what a per-process measurement resolves; size is the constraint — a transaction grows 19× to 86×. Reproducible in one command, and it takes no position on whether Bitcoin should change anything. The measurement →
And what that costs a base layer: the second half, computed. At the measured sizes a block at v0.1's own 32 MiB ceiling settles 281,000 to 1,270,000 one-input spends a day against 24 million under ECDSA, and a block at the 2010 1 MB rule 8,000 to 38,000 against 720,000; a hundred million outputs need 79 to 356 days of full blocks to each move once at 32 MiB and seven to thirty-three years at 1 MB. The spend that migrates an exposed key is signed under the old scheme, so no second layer can make it. Populations are parameters; the script carries the measured sizes as constants. The derivation →
Bitcoin's script limits were retrofitted, and here are the dates. The caps on pushed-element size, script size, stack depth and numeric operands are commonly taken to be part of the original design. None of the four is in the January 2009 release. All four arrive on 29 July 2010 in a commit whose message describes a makefile change, and the element cap is tightened 5,000 → 520 seventeen days later under the message “misc changes”. Every commit in the window was fetched and tested individually; the genesis interpreter was compiled and executed rather than read. It claims no priority — the commits are public — only the dating, the method, and the artifacts. The note →
The 1 MB block-size limit was retrofitted in two steps. The constant
MAX_BLOCK_SIZE = 1000000 was defined on 15 July 2010 in a commit about OpenSSL linkage and a tray icon,
and only the miner honoured it. It became a rule of block validity on 7 September 2010, activating at block 79,401,
in a commit whose message reads “cleanup”. The January 2009 release already rejected blocks over 32 MiB.
Every line is a fetched commit; the note claims no priority and takes no position on any block size.
The note →
Every consensus rule Bitcoin acquired after January 2009, dated to its commit. The retrofit atlas gives each rule its origin commit, the commit message verbatim, the lines the diff adds and removes, and whether the message describes the change: for 6 of the 13 rules with a commit it does not. Time-based locks arrived on 29 October 2009; cumulative-work chain selection on 25 July 2010 under a message about JSON-RPC authentication; two rules were consensus before anyone wrote them, a database's lock table (the March 2013 fork) and OpenSSL's signature parser (BIP 66). One constitution row each, with the executed witness or the word open. The atlas →
Two essays from the record. In December 2010 the account that authored Bitcoin argued, in seven dated posts, against piling other systems into its chain and for separate chains sharing proof-of-work: the layering principle in its author's words, quoted verbatim. BitDNS and layering → And the vocabulary round trip: fifteen opcodes the January 2009 interpreter executes natively were disabled on 15 August 2010 under “misc changes”; a December 2023 paper verifies any computable function on Bitcoin without a rule change, from hashlocks, timelocks and Taproot trees, at a cost it states plainly. The round trip →
Three policies the origin shipped, and what 2010 did to them, executed. The January client replaces a held transaction with a newer version of itself (same inputs, higher sequence number); that was disabled on 19 August 2010 under a message about block-index checking. It names no block but the genesis; hard-coded checkpoints arrived on 17 July 2010 under “security safeguards”, five by 15 August. Its one fee rule applied only when building and sending; relay began refusing under-paid transactions on 12 December 2010. Each ported line for line, side by side. And the 15 August 2010 overflow incident, dated to the minute from the commits, the author's posts and the chain's own timestamps. The ports → The incident →
Related research (a separate project). satoshi‑onchain — a reproducible verifier + Patoshi classifier for the original Satoshi's on‑chain footprint (the genesis block, the ~1.1M‑BTC Patoshi mining pattern, the block‑170 Satoshi→Finney spend) — statistical, not cryptographic, in the same evidence‑tiered style. A companion angle on the same origin: this lab reconstructs the earliest code; that one measures the earliest chain.