◆ Original Bitcoin Laboratory · Evidence · JAN09-EXECUTED · not money
Two unmodified January 2009 v0.1.1 bitcoin.exe
binaries — in network-isolated Windows VMs, discovering each other over the client's own hard-coded IRC
path — re-derive the historical genesis and then produce, relay, sustain, reorganise and spend
real blocks. Every result below is verifiable straight from the raw blk0001.dat
block bytes. Not the Bitcoin. Not money.
Both nodes recognise the historical genesis. Node B — the released miner is peer-gated
(while(vNodes.empty())), so it can only start once it
has a peer — mines block 1 at real difficulty 1; node A receives it over the
P2P link and accepts it. Both end holding the byte-identical two-block chain.
Node B mines three blocks in succession and node A validates and accepts every one, climbing 1→2→3 in lockstep — a byte-identical four-block chain. A follow-on run had both nodes mining and accepting each other's blocks to a 14-block chain including genesis (best-chain height 13), byte-identical on both, which persisted across a guest restart with zero orphans.
From the shared height-13 tip, node A mines its own block 14. The network is then
partitioned (node B's virtual cable pulled); in isolation node B mines a
competing block 14 and extends to 15 — one block longer. On reconnect node A's
binary fires *** REORGANIZE ***, orphans its own
block, and adopts node B's longer chain. Both converge on one tip; node A retains the
valid orphan (lost only on height) — an exact +223-byte on-disk delta, one v0.1 block.
A coinbase matured under the client's own rule — 120 confirmations, not 100: main.h
sets COINBASE_MATURITY = 100 but main.cpp:544 withholds a generated
coin for twenty blocks beyond it. Node B then spent it. Transaction
f4309c… — one input, one 50.00 output, no change and no fee — was created on node B
(SendMoney: f4309c) and accepted by node A across the wire
(AcceptTransaction(): accepted f4309c appears in both nodes' logs; the same
transaction id on both sides is the relay itself). It was mined into block
00000000b4ca03f9… at height 122, which carries two transactions: its own coinbase
f14a63… and the spend. Both nodes converged on that tip.
The binaries are bound to the run, not merely present on disk. Each node's executing image was
hashed before and after: identical PID and process start time in both records
(node A 4468 from 01:56:52Z, node B 7632 from 01:57:09Z), bitcoin.exe
fbcac071… in all four — one unchanged process on each node, running ~65 hours,
produced these blocks.
This closes the R-series. Value transfer on the unmodified 2009 client is now executed, not modelled. What remains modelled is mining across a difficulty retarget window; the chain never left difficulty 1. No value is assigned to any of it.
| This page | Satoshi’s binary, Satoshi’s genesis, two nodes. Nothing was written by us:
the client is fbcac071… as released in January 2009, and the chain it builds descends from the
real 000000000019d668…. The evidence class is JAN09-EXECUTED. |
|---|---|
| Not this page | The laboratory also runs a chain called Bitcoin — its own
genesis 00000000ad12f3ec…, coinbase quoting The Times of 3 August 2026. It is
executed evidence too, and every block after its genesis was mined by our own published release. But it is
one node, our genesis, our build — not two nodes on Satoshi’s. Folding it into the R-series would
flatten exactly the line this laboratory exists to hold.
the Bitcoin chain → |
| Why keep them apart | A witness and a demonstration answer different questions. The R-series asks what does the 2009 client do when two of them meet — and we are not the author of the answer. The Bitcoin chain asks can that client still be built, released and run today — where we authored the genesis and the build. Merging them would let the second borrow the first’s authority. |
| Genesis | 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26fthe real 3 Jan 2009 block 0 — The Times Chancellor coinbase — re-derived by the unmodified binary. |
|---|---|
| Binary | bitcoin.exe sha256 fbcac071d92e26d82ec917214e334bd43850c0691f113bab1d4741c9bdd30d2dSatoshi’s released January 2009 executable. It is v0.1.1, built 10 Jan 2009 — the archive is distributed everywhere as bitcoin-0.1.0.rar, and that label is the ecosystem’s, not the bytes’:
the PE TimeDateStamp reads 2009-01-10 23:16:00 UTC, two days after v0.1.0 was announced.
No result on this page changes — main.cpp is untouched between the two, so the genesis
and every consensus rule exercised here are identical. Retrievable from
cdn.nakamotoinstitute.org/code/bitcoin-0.1.0.rar; same on both nodes.
the six checks → |
| Network | VirtualBox Internal Network 172.20.0.0/24, no gateway, no DNS, firewall off. Node A 172.20.0.1, node B 172.20.0.2. |
| Discovery | the client's own hard-coded IRC path, reproduced against a minimal in-network daemon (hosts override) — never the historical Freenode. |
| Status | Isolated network · the real historical genesis · no value assigned by design. A Bitcoin, not the Bitcoin. |
Each verifier re-derives its result from the raw block bytes — it reads the
blk0001.dat files named on its command line, checks the genesis, proof-of-work,
linkage, best chain, and (for the reorg) the retained orphan. Get the block files + verifiers from the archival deposit
(or the findings folders in the repo):
# every file in the deposit sha256sum -c SHA256SUMS # R3 — genesis + first mined/relayed block python 2026-07-31-twonode-mined-block/verify_r3.py \ 2026-07-31-twonode-mined-block/nodeA/blk0001.dat \ 2026-07-31-twonode-mined-block/nodeB/blk0001.dat # R4a — sustained 14-block chain incl. genesis, byte-identical both nodes python 2026-08-01-sustained-relay/verify_r4.py \ 2026-08-01-sustained-relay/run-b-14/nodeA_blk0001.dat \ 2026-08-01-sustained-relay/run-b-14/nodeB_blk0001.dat # R4b — reorganisation: node A 1 orphan, both converge on one tip python 2026-08-02-reorg-partition/verify_r4.py \ 2026-08-02-reorg-partition/nodeA_blk0001.dat \ 2026-08-02-reorg-partition/nodeB_blk0001.dat # R4c — relayed spend: both at height 122 on one tip; block 122 holds 2 transactions python derivatives/r4/verify_r4.py \n 2026-08-06-relayed-spend/nodeA/blk0001.dat \n 2026-08-06-relayed-spend/nodeB/blk0001.dat # and the relay itself — the SAME txid in both nodes' logs grep -n "AcceptTransaction(): accepted f4309c" \n 2026-08-06-relayed-spend/nodeA/debug.log \n 2026-08-06-relayed-spend/nodeB/debug.log
What this establishes, honestly. These runs are author-reported and made inspectable by publishing the raw block files, the node logs, and re-derivation scripts — anyone can re-run the verifiers on the bytes, and reproduce the runs from the released binary and the runbook. What they show is behaviour: an unmodified 2009 client still boots on its real genesis and does the full job of a node — mine, relay, sustain a chain, and reorganise. They do not, and cannot, decide which live network today "is" Bitcoin — that is convention, not fact, and this lab privileges none. The archival deposit (with DOI) makes the evidence citable; it is not money — isolated networks, no premine, no value assigned.