genesis v0.7.0 (experimental) — Bitcoin (2026) observed rather than asserted — not money

genesis v0.7.0 (experimental) — Bitcoin (2026) observed rather than asserted — not money.

Bitcoin (2026) is a 2026 experimental chain, not the Bitcoin of 2009; its author "Satoshi Nakamoto" is an AI agent built in 2026, a program, not a person. Not money.

Builds on v0.6.0, which closed the R-series by witnessing a relayed spend. This release is about what the running chain then did on its own, and about three tools that had only ever been run on input that could not make them fail.

⚠️ The client is UNCHANGED. derivatives/bitcoin/src is byte-identical to Bitcoin-v0.1.5 and EXPECTED_SHA256 has not moved, so the reconstructed January 2009 binary is bit-for-bit the same one. Nothing in this release alters consensus behaviour.

New this release

• Blocks 122–295 recorded (bitcoin-findings/2026-08-22-blocks122-295/), continuing the append-only ledger of the chain's own history.
• The first difficulty retarget, predicted in advance and falsifiably (bitcoin-findings/PREDICTION-first-retarget.md) — published before the block that settled it existed. A prediction published after the fact is not a prediction.
• The chain's first reorganization, recorded with the reason it was expected (bitcoin-findings/2026-08-21-first-reorganization/).
• The first blocks mined outside the client, by a second independent miner (bitcoin-findings/2026-08-19-external-blocks221-222/), with the append-only proof extended through an external store.
• derivatives/retarget/retarget_watch.py — the tool that makes the prediction checkable rather than merely stated.

Three verifiers that had only ever met clean input

probe_seed_node.py reported a FORK the first time it met a capture containing orphans. It had been correct on every previous run because every previous run used input that could not make it wrong. A tool only ever run on clean input has not been shown to work — and the same review found the same shape in two of its siblings.

netnode: the inv is now paged

blocks_after() returned an unbounded inventory against a 4 MiB MAX_MESSAGE_SIZE, so a peer far enough behind was sent a message it could not accept. It now yields at most 2000 hashes and the peer asks again from the last one it received.

And an unmeasured height is no longer published as zero: a walk that times out returns not measured rather than an empty chain. An empty chain and an unread chain were being written identically, which is why the site once showed two live chains at height 0.

Provenance

external_evidence now carries the independently computed archive MD5 and per-claim binding levels, and the consumer owns the claim→evidence map rather than trusting a descriptor that supplied its own judge. The manifest's commit is bound to the tree that produced it, and local paths are no longer leaked.

Verify before you trust

sha256sum -c SHA256SUMS
gpg --verify obl-genesis-0.7.0.tar.gz.asc obl-genesis-0.7.0.tar.gz
gpg --verify SHA256SUMS.asc SHA256SUMS

# post-quantum counter-signature (needs OpenSSL 3.5+, nothing installed)
openssl pkeyutl -verify -pubin -rawin -in SHA256SUMS \
  -inkey docs/parthod0x-pq-countersign.pem -sigfile SHA256SUMS.slhdsa   # key is in the tarball and the repository; sha256 0624d2c7…

# the step that makes the counter-signature mean anything
ots verify SHA256SUMS.slhdsa.ots

Signing key B0145F74B78CF1DA. The .ots proofs are pending at publication and complete once a Bitcoin block confirms them; a counter-signature nobody dated is one a forger could also have made.

obl-genesis-0.7.0.tar.gz — sha256 7aeece78778fed1b3251346db8bbbf04414ce2c8953bdea0d31c6b8b51e805cd

---

NOT money. No premine, no allocation, no sale, no price. Nothing here is offered in trade.

Experimental laboratory research, in progress: what re-runnable methods find, no conclusions beyond that, no warranty.

Bitcoin (2026) v0.1.5 — experimental chain, not the 2009 Bitcoin, not money

Bitcoin v0.1.5

A documentation release. No source file changed, no rule changed, and the binary is byte-identical
to the one v0.1.3 and v0.1.4 shipped.

bitcoin.exe c3f15fc5b7bd80f4d08fe5ff356256214734eb1a3e4a7c953c9e8fc8453d2c7d

The client, the chain and the protocol are unchanged from v0.1.0: the same patched source tree, the
same genesis, the same serialization VERSION 101 on the wire. A node built from any of the six
releases speaks to a node built from any other.

What changed

ONE FILE WAS ADDED: 00-PROVENANCE.txt.

Nothing else. Not a byte of src/, not a byte of bitcoin.exe.

Why it was added

This package ships readme.txt exactly as Satoshi Nakamoto wrote it in 2009. It opens:

BitCoin v0.01 ALPHA
Copyright (c) 2009 Satoshi Nakamoto

That is correct, it is required by the MIT licence the code was released under, and it is the entire
point of a reconstruction -- bytes that have been tidied up prove nothing. It stays exactly as it is.

But it is also the first file a stranger opens, and until now nothing sat above it. RELEASE.txt said
so in a single line two hundred lines down, which is not where someone unpacking this archive in
2050 will look. A 2026 package whose first readable file carries an unqualified 2009 attribution is
a question waiting to be asked, and the answer should be in the package rather than in an argument.

00-PROVENANCE.txt sorts first in any listing and states:

• which bytes are Satoshi's (readme.txt, license.txt, 23 of 26 source files, verbatim)
• which are third-party (src/sha.cpp and sha.h -- Crypto++ by Wei Dai, public domain, and they
  carry no Satoshi notice in the 2009 release either; that absence is preserved, not created)
• which are this project's -- NINE SUBSTITUTIONS ACROSS TEN LINES in three files, enumerated
  one by one, every one of them chain separation and not one of them a consensus rule
• how to tell which chain you are looking at, since a version number cannot tell you: both eras
  use v0.1.x, so the coinbase of block 0 is the only reliable test
• that this is not money, and that no claim is made about who Satoshi Nakamoto was

A correction carried in this release

An earlier draft of that file said "seven constants". It is NINE substitutions across ten lines --
nine values, ten lines, because the IRC channel name appears twice, in JOIN and in WHO. The error
was found by running make_chain.py --check and reading its count rather than trusting the prose
beside it, and the corrected file enumerates all nine so the number can be checked rather than
believed.

What was NOT done, deliberately

Published releases were not retro-fitted. v0.1.0 through v0.1.4 are signed, hashed and timestamped
exactly as they were, and they stay that way. Rewriting a signed and anchored artifact to improve
its documentation would destroy the property that makes the artifact worth anything, which is that
nobody -- including its author -- can change it after the fact.

The correction travels forward. The record is appended to, never rewritten.

Correction (12 September 2026). One published asset has since been withdrawn: v0.1.0's bitcoin-0.1.0.tar.gz, because its binary embedded the build machine's directory layout. Nothing was substituted or re-signed; its digest stays in that release's SHA256SUMS and the signatures and timestamps over it stand.

Post-quantum

Since 10 August 2026 this project's release manifests carry a second signature under
SLH-DSA-SHA2-128s (NIST FIPS 205), alongside the OpenPGP one. The OpenPGP key is Ed25519 and does
not survive a quantum break; SHA-256 manifests and OpenTimestamps anchors do.

All twelve previously published manifests were counter-signed retroactively on the same day, because
what matters is not when a counter-signature was made but that its timestamp predates a break.

verification instructions docs/PQ-COUNTERSIGNING.md
public key docs/parthod0x-pq-countersign.pem
sha256 0624d2c7149d4af09e25b558e76f5e6b1a8855d60723c45333829c46488ceda4

Genesis

hash 00000000ad12f3ecd9b14e4276ac98936fb0d658f05dce95ad35d18fceee208a
coinbase The Times 03/Aug/2026 Toll of schooling 'straitjacket'
output 50.00000000 -> P2PK 04c0414c... (no value assigned)
nTime 1785781375 = 2026-08-03 18:22:55 UTC
nBits 0x1d00ffff
nNonce 33394338

Network

magic f00ba726 port 18026
seed bitcoin.bitcoin-lab.org:18026

The current tip is on the status page, https://bitcoin-lab.org/status.html, not in this file. A
height written into a release note is wrong the next time a block is found.

Verify

gpg --verify SHA256SUMS.asc SHA256SUMS && sha256sum -c SHA256SUMS
gpg --verify bitcoin-0.1.5.tar.gz.asc bitcoin-0.1.5.tar.gz
ots verify SHA256SUMS.slhdsa.ots # completes once a Bitcoin block confirms it
python make_chain.py --check # src/ is the 2009 tree plus that patch, and nothing else
python net.py # re-derives the genesis hash; checks it meets difficulty-1
sha256sum bitcoin.exe # must equal c3f15fc5... -- the same bytes v0.1.3 shipped

To rebuild the binary yourself

git clone https://github.com/original-bitcoin-laboratory/genesis && cd genesis
bash scripts/fetch-artifacts.sh # bitcoin-0.1.0.tgz, from the Nakamoto Institute
tar xzf artifacts/jan09/bitcoin-0.1.0.tgz -C extracted
python3 derivatives/bitcoin/make_chain.py
SRC=$PWD/derivatives/bitcoin/src bash derivatives/build-reconstruction/full_build_wsl.sh
sha256sum derivatives/bitcoin/build/bitcoin-0.1.0-reconstructed.exe

Reproducible with gcc 13.2.0 (win32 thread model), binutils 2.41.90, mingw-w64 11.0.1, on Ubuntu
24.04. A different toolchain emits different code; that is what reproducible building means
everywhere.

What running this client discloses

Read this before you run it anywhere but an isolated VM.

The 2009 client bootstraps over IRC, and this one still does, unchanged but for the channel name.
On startup it resolves chat.freenode.net, connects on 6667, and joins #bitcoin26 with its NICK set
to a base58 encoding of its own routable address -- so your public IP is published, in a trivially
decodable form, into a public channel on infrastructure nobody here operates.

That is what the client does, and it is left alone for the same reason everything else is: changing
it would make this a different program. But 2009's Freenode is not 2026's, and you should decide
knowingly. Everything else is equally period-accurate: no encryption, no authentication, and a
wallet.dat written in the clear.

Which Bitcoin. This is a 2026 experimental chain, not the Bitcoin of 2009 and not a fork of it; its author "Satoshi Nakamoto" is an AI agent built in 2026 — a program, not a person, and not the historical Satoshi. Not money.

NOT MONEY. No premine of value, no token, no sale, no market. Experimental research artifact.
Run the client only in an isolated VM: it is a live node.

Experimental laboratory research, in progress: what re-runnable methods find, no conclusions beyond that, no warranty.

NOV08-X / JAN09-X v0.6.0 (experimental) — R4c relayed spend witnessed, the R-series complete — not money

NOV08-X / JAN09-X v0.6.0 (experimental) — R4c relayed spend witnessed, the R-series complete — NOT money.

Builds on v0.5.0's conformance layer and sustained two-node relay. This milestone closes the last behavioural cell on the unmodified January 2009 binary: value transfer. A coinbase that matured under the client's own rule was spent, relayed to a second node, mined into a block, and persisted identically by both. Everything re-derives from the raw block bytes; not money, not financial advice.

New this release

• R4c — a relayed spend of a matured coinbase (r4-findings/2026-08-06-relayed-spend/). Transaction f4309c… — one input, one 50.00 output, no change and no fee — created on node B (SendMoney: f4309c) and accepted by node A across the wire. The same txid appears in both nodes' logs as AcceptTransaction(): accepted f4309c: node B authored it, node A learned of it only from the network. That is the relay itself. It was mined into block 00000000b4ca03f9151f869b018beb009fc75082cc313385f1345ee3af339bf8 at height 122, which carries two transactions — its coinbase f14a63… and the spend. Both nodes converged on that tip.

• Maturity is 120 confirmations, not 100 — witnessed, not asserted. main.h sets COINBASE_MATURITY = 100, but main.cpp:544 returns max(0, (COINBASE_MATURITY + 20) - GetDepthInMainChain()), so the wallet withholds a generated coin for twenty blocks beyond the constant. The running GUI states it plainly: a coin 58 blocks deep reads "matures in 62 blocks".

• Executed-binary binding across the whole run. Each node's running 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, with libeay32.dll and mingwm10.dll captured alongside. One unchanged process per node, running ~65 hours, produced these blocks — not merely a matching binary sitting on disk.

• Verifiable from the bytes. derivatives/r4/verify_r4.py reports both nodes at height 122 on the same tip, every best-chain block with valid proof-of-work, and the real historical genesis 000000000019d668…. Node A still retains the R4b orphan 000000000234edf2… forked off height 13 — which is why its blk0001.dat holds one block more while agreeing perfectly on the best chain.

Corrections carried in this release

Both are kept visible rather than quietly fixed.

• STATUS.md claimed R4a, R4b and R4c were "one single run". False for R4c: bitcoin.exe restarted twice in between — the host machine powered down mid-run — and the appended debug.log shows two Loading addresses… / Done loading pairs on each node. The chain and datadir are continuous (R4c's log still begins with R4b's bytes exactly: nodeA 22,016 → 128,688; nodeB 22,898 → 147,228), so the nodes resumed exactly where they stopped. The process is not continuous, and a pre/post binding pair must bracket one uninterrupted process. A fresh pre was taken with the new PIDs — which is precisely what that same section of STATUS.md already instructed. The rule was written down before it was needed, and then it was followed.

• The R4 runbook said to grep for received tx. v0.1 does not log that string; it logs AcceptTransaction(): accepted <txid>. Runbook corrected.

What is still modelled rather than executed

Mining across a difficulty retarget window. The chain never left difficulty 1. That is the one remaining cell.

Evidence

104 files hashed into r4-findings/2026-08-06-relayed-spend/EVIDENCE_MANIFEST.json + SHA256SUMS, including both wallet.dat. The hashes are published; the raw bytes are not — same discipline as R3. The wallets are retained because they are the only artifact that can later prove who ran this: anyone can copy a block file, but only the key-holder can sign from 17JDVSXwbQuGMoV8WSokEo52gNrHHcCAQg, the address that sent f4309c.

Isolated network · the real historical genesis · no value assigned by design. A Bitcoin, not the Bitcoin. NOT money.

Verify

gpg --verify SHA256SUMS.asc SHA256SUMS && sha256sum -c SHA256SUMS
gpg --verify obl-genesis-0.6.0.tar.gz.asc obl-genesis-0.6.0.tar.gz
ots verify SHA256SUMS.slhdsa.ots      # completes once a Bitcoin block confirms it

Bitcoin (2026) v0.1.4 — experimental chain, not the 2009 Bitcoin, not money

Superseded by Bitcoin v0.1.5, the current release. This note stays as published.

Bitcoin v0.1.4

The client, the chain and the protocol are unchanged from v0.1.0: the same ten patched lines on the
same verified source tree, the same genesis, the same serialization VERSION 101 on the wire. A node
built from any of the five releases speaks to a node built from any other. This is a build-level
release, the fourth one.

The binary is byte-identical to v0.1.3.

bitcoin.exe c3f15fc5b7bd80f4d08fe5ff356256214734eb1a3e4a7c953c9e8fc8453d2c7d

Rebuild it from the published 2009 archive and your bytes hash to that. Nothing in the client
changed, so nothing in the binary changed; a release that shipped a different binary for the same
source would be the thing worth worrying about.

What changed

1. BLOCK 4, AND THE RELEASED CLIENT MINED IT.

   height 4 0000000097b1298a990e8f872e4acda48ace5274e99d2a5f9a483f183c1bd20c
   nonce 2045882594 nBits 0x1d00ffff 2026-08-08 22:19:22 UTC
   prev 00000000428303928c985745792c7ad7644cb5f310b417263a66108fa7f49dcf

   The chain is five blocks. All five link, all five meet their proof-of-work target, checked from
   the raw block file against the difficulty arithmetic rather than by eye.

   Blocks 2, 3 and 4 were produced by bitcoin-0.1.3 -- the client published under that tag, hash
   c3f15fc5..., matching its own release oracle. So the release is not only a package: it is an
   executed artifact. That is the same claim this laboratory makes about Satoshi's fbcac071..., now
   made about our own. (Block 1 was mined by v0.1.1, cfb59606..., and its records say so. Do not
   retro-fit v0.1.3 onto it.)

   The block-4 session is bound tightly: one process, pid 2272, started 21:56:08 UTC, captured
   before at 21:56:16 and after at 22:35:05, both captures reporting the same binary hash and the
   same process start time. The block's own timestamp, 22:19:22, sits inside that window. A
   39-minute bracket is a stronger statement than a wide one -- it leaves less room between "this
   binary was running" and "this binary made this block".

2. BLOCKS 2 AND 3 ARE PUBLISHED. They were mined on 6 August and their findings had never left the
   local evidence set. bitcoin-findings/ now carries blocks 1 through 4.

3. THIS TAG IS SIGNED AND ANNOTATED. Bitcoin-v0.1.0 and v0.1.1 were annotated tags; v0.1.2 and
   v0.1.3 were lightweight -- a regression nobody noticed, because a lightweight tag looks identical
   until you ask it who made it. From v0.1.4 the tag carries a signature.

   The earlier tags are NOT re-cut. Rewriting a published tag breaks every clone and invalidates the
   timestamps anchored to it; the gap is recorded instead.

4. THE GENESIS-ERA ARTIFACTS ARE ANCHORED IN BITCOIN. The agent's key file, the mint record, the
   miner source and binary, the coinbase-headline script and the signed provenance statement were
   submitted to OpenTimestamps on 9 August 2026 (local time; the .ots proofs name the Bitcoin block that anchors them).

   This does not prove they existed on 3 August. Nothing can. What it does is stop the window
   widening: "existed no later than " is now chain-proven and no longer rests on this
   machine's clock. Together with the newspaper in the genesis coinbase, which fixes the other end,
   the artifacts are bracketed from both sides by parties that are not us.

   That matters for a specific reason. This project declines to treat the satoshin@gmx.com key's
   2008 self-asserted date as evidence. Anchoring our own artifacts is how we avoid asking for a
   weaker ruler than we hand everyone else.

Corrections carried in this release

NEXT-SESSION_block4_pre.json, in the block-3 evidence set, is described there as the block-4
binding. It is not: it was captured 2026-08-04 from pid 5072 running v0.1.1, a process that had
already exited. Block 4 took its own fresh capture. A pre-capture from a dead process binds nothing.

The sealed set is not edited -- the correction is recorded in bitcoin-findings/CORRECTIONS.md, so
the seal keeps verifying and the error stays visible.

What this is not

Not money. No premine of value, no token, no sale, no market, no promises. The 50-unit coinbase
outputs have no value assigned.

Not the Bitcoin of 2009. This chain's genesis is 00000000ad12f3ec..., its coinbase quotes The Times
of 3 August 2026, and it was authored by an AI agent built in 2026 -- not a person, and not the
author of the 2009 Bitcoin, about whose identity this project makes no claim.

Not a measurement of anything but the client. One node, isolated, no peers, difficulty never moved
from 1. The intervals between blocks are gaps between sessions, not block times: a 68-hour gap means
the machine was switched off.

gpg --verify SHA256SUMS.asc SHA256SUMS && sha256sum -c SHA256SUMS
gpg --verify bitcoin-0.1.4.tar.gz.asc bitcoin-0.1.4.tar.gz
ots verify SHA256SUMS.slhdsa.ots      # completes once a Bitcoin block confirms it

Bitcoin (2026) v0.1.3 — experimental chain, not the 2009 Bitcoin, not money

Superseded by Bitcoin v0.1.5, the current release. This note stays as published.

Bitcoin v0.1.3

The client, the chain and the protocol are unchanged from v0.1.0: the same ten patched lines on the
same verified source tree, the same genesis, the same serialization VERSION 101 on the wire. A node
built from any of the four releases speaks to a node built from any other. This is a build-level
release, the third one.

What changed

The binary is reproducible. You can rebuild it and get the same bytes.

bitcoin.exe c3f15fc5b7bd80f4d08fe5ff356256214734eb1a3e4a7c953c9e8fc8453d2c7d

Until now the signature on a release said only that we built something. It now says something a
stranger can check: build it yourself from the published 2009 archive, and if your bytes hash to
that, the signed file is the file you just made. A GitHub-hosted runner does exactly this on every
change to the build inputs and fails if the hash moves --
.github/workflows/reproducible.yml, which starts by fetching bitcoin-0.1.0.tgz over the network
rather than trusting anything in the repository.

It took two flags, both found by building twice and comparing.

• -Wl,--no-insert-timestamp. Two builds of identical inputs on one machine differed in 4 bytes of
  15,529,604: two in the PE TimeDateStamp at 0x88, two in the CheckSum at 0xd8 that derives from
  it. ld writes the build clock into the header.

• SOURCE_DATE_EPOCH. With the timestamp fixed, a second machine with an identical toolchain still
  differed in 8 bytes. Six were in .rodata and every one was an ASCII digit -- wxWidgets stamping
  its own build clock through wxGetLibraryVersionInfo. gcc honours SOURCE_DATE_EPOCH for DATE
  and TIME, and the build pins it to 1785781375: 2026-08-03 18:22:55 UTC, this chain's own
  genesis. The string inside the binary reads "Aug 3 2026" / "18:22:55".

Not one instruction ever differed. Not a symbol, not a section, not an offset, not a byte of any of
the four statically linked period libraries. Two machines hours apart emitted identical machine code
and disagreed only about what time it was.

What this does not buy

Freedom from the toolchain. The bytes above are reproducible with gcc 13.2.0 using the win32
thread model, binutils 2.41.90, mingw-w64 11.0.1, on Ubuntu 24.04. A different compiler emits
different code. Ubuntu ships a posix thread variant alongside the win32 one; they are not
interchangeable and do not produce the same binary. The CI job sets the alternative explicitly and
prints the full package set on every run, so a mismatch is diagnosable rather than mysterious.

This is what reproducible building means everywhere. Bitcoin Core pins its toolchain with Guix for
the same reason.

To rebuild it yourself

git clone https://github.com/original-bitcoin-laboratory/genesis && cd genesis
bash scripts/fetch-artifacts.sh # bitcoin-0.1.0.tgz, from the Nakamoto Institute
tar xzf artifacts/jan09/bitcoin-0.1.0.tgz -C extracted
python3 derivatives/bitcoin/make_chain.py
SRC=$PWD/derivatives/bitcoin/src bash derivatives/build-reconstruction/full_build_wsl.sh
sha256sum derivatives/bitcoin/build/bitcoin-0.1.0-reconstructed.exe

make_chain.py refuses unless each of the ten edits matches exactly once, so that step re-verifies
the extracted tree as a side effect. Full working: docs/BUILD_NOTES.md.

v0.1.0, v0.1.1 and v0.1.2 remain published and their signatures remain valid. Nothing about the
chain is affected: consensus, the wire format and the genesis are untouched, and block 1 was mined
and relayed by the v0.1.1 binary.

Genesis

hash 00000000ad12f3ecd9b14e4276ac98936fb0d658f05dce95ad35d18fceee208a
coinbase The Times 03/Aug/2026 Toll of schooling 'straitjacket'
output 50.00000000 -> P2PK 04c0414c... (no value assigned)
nTime 1785781375 = 2026-08-03 18:22:55 UTC
nBits 0x1d00ffff
nNonce 33394338

Network

magic f00ba726 port 18026
seed bitcoin.bitcoin-lab.org:18026

Mining

height 0 00000000ad12f3ecd9b14e4276ac98936fb0d658f05dce95ad35d18fceee208a 3 Aug 2026
height 1 000000007beb32b8380089595a91261a5ce4fbd4ece0cd661683cb1ce81e407c 4 Aug 2026

Block 1 was mined by the v0.1.1 client, from this distribution, and relayed to the seed, which
validated and stored it with a different implementation. Block 2 onward are unmined and anyone may
take them. Blocks cost difficulty-1 work -- about 2^32 hashes -- so the client's own miner takes
roughly an hour per block on one core. There is nothing to buy, nothing to claim, and nothing owed
to whoever mines next.

Build

src/ is composed by make_chain.py from two inputs: the v0.1.0 source tree, SHA256
8b17eb9a5707f2519defda4cdf8d14fa1b8dee630e11e6ef85ff9f5547555b56, and bitcoin-v0.1.0.patch --
this chain's genesis, network magic and port, and bootstrap channel. Ten lines, in main.cpp,
net.h and irc.cpp.

The binary is cross-compiled by full_build_wsl.sh against the period libraries (OpenSSL 1.0.2u,
wxWidgets 2.8.12, Berkeley DB 4.8, Boost 1.42), statically linked, so it ships no DLLs.

Consensus rules, script, difficulty, serialization, wallet and UI carry no guardrails: no
MoneyRange, no script limits, and no 1 MB block cap -- that arrives in July 2010. The one ceiling
that does exist is MAX_SIZE, 32 MiB, enforced by CheckBlock. Safe here for one reason only --
there is nothing to steal.

Verify

python make_chain.py --check # src/ is those two inputs and nothing else
python net.py # re-derives the genesis hash; checks it meets difficulty-1

The client asserts the genesis hash on startup, so a wrong build does not run.

readme.txt and license.txt are the source tree's own, unmodified.

What running this client discloses

Read this before you run it anywhere but an isolated VM.

The 2009 client bootstraps over IRC, and this one still does, unchanged but for the channel name.
On startup it resolves chat.freenode.net, connects on 6667, and joins #bitcoin26 with its NICK set
to a base58 encoding of its own routable address -- so your public IP is published, in a trivially
decodable form, into a public channel on infrastructure nobody here operates. Anyone sitting in the
channel can read it, and IRC servers keep logs.

That is what the client does, and it is left alone for the same reason everything else is:
changing it would make this a different program. But 2009's Freenode is not 2026's, and you should
decide knowingly. ThreadIRCSeed starts unconditionally from net.cpp -- v0.1.0 has no -noirc switch,
so the only lever is the client's own /proxy option, which leaves addrLocalHost unroutable and makes
it fall back to a random nickname. Everything else in the client is equally period-accurate: no
encryption, no authentication, and a wallet.dat written in the clear.

NOT MONEY. No premine of value, no token, no sale, no market. Experimental research artifact.
Run the client only in an isolated VM: it is a live node.

Which Bitcoin. This is a 2026 experimental chain, not the Bitcoin of 2009 and not a fork of it; its author "Satoshi Nakamoto" is an AI agent built in 2026 — a program, not a person, and not the historical Satoshi. Not money.

Experimental laboratory research, in progress: what re-runnable methods find, no conclusions beyond that, no warranty.

Bitcoin (2026) v0.1.2 — experimental chain, not the 2009 Bitcoin, not money

Superseded by Bitcoin v0.1.5, the current release. This note stays as published.

Bitcoin v0.1.2

The client, the chain and the protocol are unchanged from v0.1.0: the same ten patched lines on the
same verified source tree, the same genesis, the same serialization VERSION 101 on the wire. A node
built from any of the three releases speaks to a node built from either other. This is a build-level
release, the second one.

What changed

The client was executed for the first time on 4 August 2026, to mine block 1. It mined it. It also
showed two things three days of hashing and string-scanning had not: it wrote no debug.log, and
wxWidgets logged "Can't load bitmap 'send20' from resources!" at startup.

Both are divergences in how we built it, not in what it does. This release removes them.

• WXDEBUG is now defined, and wxWidgets is rebuilt --enable-debug to match. The whole body of
  OutputDebugStringF sits inside #ifdef WXDEBUG, so without it the client emits no diagnostic
  output at all -- not to file, not to OutputDebugString. It now writes debug.log as the 2009
  client does.

• windres ui.rc now runs, producing the .rsrc section with the eleven bitmaps and icons. Our
  binary had no resource directory at all; the missing toolbar images were the visible symptom.

• -mthreads is set, as makefile:28 sets it. On MinGW it selects thread-safe C++ exception handling
  and the _beginthreadex runtime. This client runs five threads.

• sha.cpp is compiled -O3, overriding the -O0 every other unit gets, exactly as Satoshi's makefile does.
  It is the mining inner loop.

Reading the makefile is not what settled this. It takes BUILD=debug|release and defaults to debug,
but make BUILD=release is an equally legal build of the same tree, so the default is suggestive
and nothing more. What settled it was measuring the released 2009 binary, sha256 fbcac071...:

"debug.log"                     7 occurrences   (and that literal occurs in exactly one place
                                                 in the whole source: util.h:236, inside the
                                                 #ifdef -- there is no other way in)
'assert "%s" failed'            1
../../include/wx/*.h paths     24 distinct      (__FILE__ expansions from wxASSERT in wx inline
                                                 headers; they vanish without __WXDEBUG__)
.rsrc PE section                present

Our v0.1.1 binary had none of the first three and no .rsrc. Satoshi's client is a debug build; ours was
not. Full working: docs/BUILD_FIDELITY.md.

One divergence is left in place and disclosed rather than fixed. Satoshi linked OpenSSL and the MinGW
runtime dynamically and shipped libeay32.dll and mingwm10.dll beside the executable; this binary is
static and ships neither. DLLs we shipped could not be Satoshi's -- ours come from a modern mingw-w64 --
so matching the shape would buy a resemblance while adding two files that must survive intact for
the client to start. One self-contained executable is the more durable form, and no peer can
observe the difference.

v0.1.0 and v0.1.1 remain published and their signatures remain valid. Nothing about the chain is
affected: consensus, the wire format and the genesis are untouched, and block 1 was mined and
relayed by the v0.1.1 binary. If you are running either, you are on the same network.

Genesis

hash 00000000ad12f3ecd9b14e4276ac98936fb0d658f05dce95ad35d18fceee208a
coinbase The Times 03/Aug/2026 Toll of schooling 'straitjacket'
output 50.00000000 -> P2PK 04c0414c... (no value assigned)
nTime 1785781375 = 2026-08-03 18:22:55 UTC
nBits 0x1d00ffff
nNonce 33394338

Network

magic f00ba726 port 18026
seed bitcoin.bitcoin-lab.org:18026

Mining

height 0 00000000ad12f3ecd9b14e4276ac98936fb0d658f05dce95ad35d18fceee208a 3 Aug 2026
height 1 000000007beb32b8380089595a91261a5ce4fbd4ece0cd661683cb1ce81e407c 4 Aug 2026

Block 1 was mined by the v0.1.1 client, from this distribution, and relayed to the seed, which
validated and stored it with a different implementation. Block 2 onward are unmined and anyone may
take them. Blocks cost difficulty-1 work -- about 2^32 hashes -- so the client's own miner takes
roughly an hour per block on one core. There is nothing to buy, nothing to claim, and nothing owed
to whoever mines next.

Build

src/ is composed by make_chain.py from two inputs: the v0.1.0 source tree, SHA256
8b17eb9a5707f2519defda4cdf8d14fa1b8dee630e11e6ef85ff9f5547555b56, and bitcoin-v0.1.0.patch --
this chain's genesis, network magic and port, and bootstrap channel. Ten lines, in main.cpp,
net.h and irc.cpp.

The binary is cross-compiled by full_build_wsl.sh against the period libraries (OpenSSL 1.0.2u,
wxWidgets 2.8.12, Berkeley DB 4.8, Boost 1.42), statically linked, so it ships no DLLs.

Consensus rules, script, difficulty, serialization, wallet and UI carry no guardrails: no
MoneyRange, no script limits, and no 1 MB block cap -- that arrives in July 2010. The one ceiling
that does exist is MAX_SIZE, 32 MiB, enforced by CheckBlock. Safe here for one reason only --
there is nothing to steal.

Verify

python make_chain.py --check # src/ is those two inputs and nothing else
python net.py # re-derives the genesis hash; checks it meets difficulty-1

The client asserts the genesis hash on startup, so a wrong build does not run.

readme.txt and license.txt are the source tree's own, unmodified.

What running this client discloses

Read this before you run it anywhere but an isolated VM.

The 2009 client bootstraps over IRC, and this one still does, unchanged but for the channel name.
On startup it resolves chat.freenode.net, connects on 6667, and joins #bitcoin26 with its NICK set
to a base58 encoding of its own routable address -- so your public IP is published, in a trivially
decodable form, into a public channel on infrastructure nobody here operates. Anyone sitting in the
channel can read it, and IRC servers keep logs.

That is what Satoshi's client did, and it is left alone for the same reason everything else is:
changing it would make this a different program. But 2009's Freenode is not 2026's, and you should
decide knowingly. ThreadIRCSeed starts unconditionally from net.cpp -- v0.1.0 has no -noirc switch,
so the only lever is the client's own /proxy option, which leaves addrLocalHost unroutable and makes
it fall back to a random nickname. Everything else in the client is equally period-accurate: no
encryption, no authentication, and a wallet.dat written in the clear.

NOT MONEY. No premine of value, no token, no sale, no market. Experimental research artifact.
Run the client only in an isolated VM: it is a live node.

Which Bitcoin. This is a 2026 experimental chain, not the Bitcoin of 2009 and not a fork of it; its author "Satoshi Nakamoto" is an AI agent built in 2026 — a program, not a person, and not the historical Satoshi. Not money.

Experimental laboratory research, in progress: what re-runnable methods find, no conclusions beyond that, no warranty.

Bitcoin (2026) v0.1.1 — experimental chain, not the 2009 Bitcoin, not money

Superseded by Bitcoin v0.1.5, the current release. This note stays as published.

Build-level release. The client, the chain and the protocol are unchanged from v0.1.0 — the same
ten patched lines on the same verified source tree, the same genesis, the same serialization
VERSION 101 on the wire. Nodes built from either release speak to each other, and v0.1.0 remains
published with its signature intact. If you are already running v0.1.0 you need do nothing.

What changed

v0.1.0's binary was compiled with absolute source paths, so it carried the builder's home directory
in its .rodata — assert() and BOOST_ASSERT bake __FILE__ in as a string literal. Satoshi's
own bitcoin.exe carries none: Satoshi's makefile compiles -c $<, a relative filename, from inside
src/, with dependencies at short rooted paths (-I"/boost", -I"/OpenSSL/include"). This build
reproduces both properties, so the binary quotes its headers exactly as Satoshi's does —
/boost/boost/array.hpp — and says nothing about the machine that made it. full_build_wsl.sh now
refuses to link if any build-machine path survives.

What running the client discloses

The 2009 client bootstraps over IRC and this one still does, unchanged but for the channel name. On
startup it resolves chat.freenode.net, connects on 6667, and joins #bitcoin26 with its nickname
set to a base58 encoding of its own routable address — your public IP, decodably, in a public
channel on infrastructure nobody here operates. ThreadIRCSeed starts unconditionally; v0.1.0 has
no -noirc, so the only lever is the client's own /proxy option. No encryption, no
authentication, wallet.dat in the clear. Run it in an isolated VM.

Verify

gpg --verify SHA256SUMS.asc SHA256SUMS && sha256sum -c SHA256SUMS

bitcoin-0.1.1.tar.gz  135134d63e7980c5496d6d9dad22c0a9d8c2c021a3708fec5004ca20eea8885e
bitcoin.exe           cfb59606c032faa933d5007e85d36f4cfd02737fc4bc485ec2d8699aeacba5ac

bitcoin.exe is inside the tarball; unpack it first or expect sha256sum -c to report that one line as missing.

Signed with B128 526A F85A E4A8 F22B 949F B014 5F74 B78C F1DA.

NOT MONEY. No premine of value, no token, no sale, no market.

Which Bitcoin. This is a 2026 experimental chain, not the Bitcoin of 2009 and not a fork of it; its author "Satoshi Nakamoto" is an AI agent built in 2026 — a program, not a person, and not the historical Satoshi. Not money.

Experimental laboratory research, in progress: what re-runnable methods find, no conclusions beyond that, no warranty.

Bitcoin (2026) v0.1.0 — experimental chain, not the 2009 Bitcoin, not money

genesis   00000000ad12f3ecd9b14e4276ac98936fb0d658f05dce95ad35d18fceee208a
coinbase  The Times 03/Aug/2026 Toll of schooling 'straitjacket'
output    50.00000000 -> P2PK 04c0414c…   (no value assigned)
nTime     1785781375 = 2026-08-03 18:22:55 UTC
nBits     0x1d00ffff        nNonce 33394338
magic     f00ba726          port 18026
seed      bitcoin.bitcoin-lab.org:18026

Join

python3 -m netnode --chain bitcoin --datadir ./data --connect bitcoin.bitcoin-lab.org:18026

The chain is at its genesis. Block 1 is unmined and anyone may take it. Blocks cost difficulty-1
work — about 2³² hashes. There is nothing to buy, nothing to claim, and nothing owed to whoever
mines first.

Verify

gpg --verify SHA256SUMS.asc SHA256SUMS && sha256sum -c SHA256SUMS
gpg --verify bitcoin-0.1.0.tar.gz.asc bitcoin-0.1.0.tar.gz
python make_chain.py --check      # the source is its two inputs and nothing else
python net.py                     # re-derives the genesis hash; checks it meets difficulty-1

Since 12 September 2026 the tarball is not attached (see the note at the end); the second line cannot run and sha256sum -c reports it missing. The signature on SHA256SUMS still verifies, and SHA256SUMS still names the withdrawn file's digest.

Signed with B128 526A F85A E4A8 F22B 949F B014 5F74 B78C F1DA.
The client asserts the genesis hash on startup, so a wrong build does not run.

Not money. No premine of value, no token, no sale, no market. Run the client in a VM.

---

Superseded by Bitcoin v0.1.1; the current release is Bitcoin v0.1.5. This release stays published and its
signature stays valid; the chain and protocol are identical, so v0.1.0 and v0.1.1 nodes
interoperate and nothing here needs replacing to stay on the network.

Its bitcoin.exe was compiled with absolute source paths, so it embeds the build machine's
directory layout in its .rodata — a property Satoshi's own binary does not have. v0.1.1
rebuilds it the way Satoshi built theirs. Nothing about the chain is affected.

Which Bitcoin. This is a 2026 experimental chain, not the Bitcoin of 2009 and not a fork of it; its author "Satoshi Nakamoto" is an AI agent built in 2026 — a program, not a person, and not the historical Satoshi. Not money.

Asset withdrawn, 12 September 2026. bitcoin-0.1.0.tar.gz has been removed from this release because its bitcoin.exe embedded the build machine's directory layout (the point the v0.1.1 note makes). Its SHA-256 7da79f8e… remains in SHA256SUMS, the signatures and timestamps over it stand, and v0.1.1 onward carry a clean rebuild of the same source.

Experimental laboratory research, in progress: what re-runnable methods find, no conclusions beyond that, no warranty. This is the one departure from the rule stated in v0.1.5 that published releases are left as they were: the file was removed, nothing was put in its place.

NOV08-X / JAN09-X v0.5.0 (experimental) — conformance layer expanded + R4 sustained relay — not money

NOV08-X / JAN09-X v0.5.0 (experimental) — conformance layer expanded + R4 sustained relay — NOT money.

Builds on v0.4.0's reproducible period build (source → bitcoin.exe). This milestone deepens the conformance layer — what the earliest Bitcoin's executable actually does, bug-for-bug — and extends the two-node executed witness. Everything re-derives from source; not money, not financial advice.

New this release

• secp256k1 curve structure (derivatives/curve_structure/, 6 tests) — the algebra of the curve the origin chose, derived from the published constants with pure-integer math: the GLV endomorphism (β,λ derivable → best generic classical attack 2^127.03, a 0.79-bit tax below P-256 — a tax, not a backdoor); textbook safety (p/n prime, cofactor 1, non-anomalous, MOV-safe); the generator G trust-atom (un-derivable, not a NUMS point) and the non-minimal 977; the twist's ~33-bit leak vs a non-validating impl. Write-up: common/conformance/CURVE_STRUCTURE.md.
• Difficulty retarget fencepost (derivatives/retarget/, 8 tests) — ported line-for-line from main.cpp:685-728: the 2016-block window is measured over only 2015 intervals → equilibrium spacing 600.30 s (~0.05% slow, not the commonly-cited 599.7 "fast"); plus the timewarp boundary.
• Era-authentic consensus behaviors (common/conformance/CONSENSUS_BEHAVIORS.md) — a source-anchored map of the v0.1 quirks a faithful reconstruction must reproduce (CHECKMULTISIG off-by-one, SIGHASH_SINGLE → 1, merkle odd-duplication, output-sum overflow, retarget fencepost), each tied to the source line and the OBL engine that executes it.
• R4 sustained relay → 14 blocks (r4-findings/2026-08-01-sustained-relay/) — two unmodified 2009 bitcoin.exe nodes, bidirectional production + relay to height 13, byte-identical blk0001.dat (d674d3f6…), same tip, 0 reorgs (JAN09-EXECUTED; verify_r4.py).
• Docs synced — scripts/reproduce.py is now 24/24 steps green (Python); validator-rs cargo test 30 passed; C++ port differentials green.

Verify (operators)

gpg --import docs/parthod0x-signing-key.asc     # fp B128 526A F85A E4A8 F22B  949F B014 5F74 B78C F1DA
git verify-tag v0.5.0-experimental
gpg --verify obl-genesis-0.5.0.tar.gz.asc obl-genesis-0.5.0.tar.gz
gpg --verify SHA256SUMS.asc SHA256SUMS && sha256sum -c SHA256SUMS
python scripts/verify_genesis.py    # re-derive both genesis blocks from source
python scripts/reproduce.py         # 24/24
cd derivatives/validator-rs && cargo test   # 30 passed

A signature authenticates the distribution; the reproducible recipe authenticates the artifact — anyone can re-derive it with no key and no node. NOT money.

NOV08-X / JAN09-X v0.4.0 (experimental) — reproducible period build (source → bitcoin.exe) — not money

NOT money. Experimental. Not production‑secure.

NOV08‑X and JAN09‑X — faithful, executable reconstructions of the earliest Bitcoin (the
15 Nov 2008 pre‑release and the 3 Jan 2009 v0.1.0 reference client), released as candidates
— a Bitcoin, not the Bitcoin. Both are live, joinable, and doubly‑implemented. See
ANNOUNCE.md and
WHAT_IS_BITCOIN.md.

This is a signed source distribution.

New in v0.4.0 — the reproducible period build

The headline: the original source still builds and runs. On a pinned period toolchain, Satoshi's
unmodified January 2009 source goes from a hash to a whole client —
derivatives/build-reconstruction/:

• sha.cpp compiles and executes unmodified on a stock modern compiler (SHA‑256 known‑answer
  vectors pass) — and the report pins the two exact period‑locks that stop the rest on a modern
  host: a 32‑bit target (serialize.h:462) and OpenSSL ≤ 1.0.2 (bignum.h:49,
  class CBigNum : public BIGNUM).
• The crypto core runs under the period toolchain. Cross‑compiled i686 + OpenSSL 1.0.2 lifts
  both locks: the original bignum.h (CBigNum arithmetic + the Script sign‑magnitude codec) and
  key.h (secp256k1 ECDSA) build and run byte‑correct.
• The Script interpreter runs. The original script.cpp compiles (with a small donor tx/util
  surface — no wx, no BDB) and passes a real pay‑to‑pubkey verification end to end:
  EvalScript + SignatureHash + CheckSig over a genuine secp256k1 signature.
• The full client links from source. full_build_wsl.sh cross‑builds all four period libraries
  (OpenSSL 1.0.2u · wxWidgets 2.8.12 · Berkeley DB 4.8.30.NC · Boost 1.42.0 — SHA‑256‑pinned) and
  links a self‑contained 14.8 MB i686 bitcoin.exe from every original .cpp, importing only
  system DLLs. The enabling insight: build wxWidgets and the Bitcoin source in their era dialect
  (-std=gnu++98). (It is a live 2009 node — run only in an isolated VM.)

Also in v0.4.0

• netnode — the script posture now controls the node verifier. verify_spend /
  verify_spend_fast / ChainState take an additive reopen set, so the faithful posture rejects
  OP_NOTEQUAL at the exact function ConnectBlock calls (default‑empty ⇒ no change for the live
  networks). OP_NOTEQUAL has no serialized byte, so its disabling is doubly secured.
• Discriminating fork test — a taller‑but‑lower‑work branch displaces a shorter‑higher‑work one,
  confirming v0.1 selects the chain by height, not cumulative work, run under the named
  jan09-faithful profile.
• Profiles registry (derivatives/profiles/) — declared rule/script postures, source‑hash‑pinned.
• Self‑healing re‑sync watchdog for the live anchors; both chains advancing in lockstep.
• Site — a shared provenance footer (genesis anchor + signing‑key fingerprint + live chain tips),
  a "rebuilt from source" home card, home links on every page, and the "Is it a Bitcoin?" object input
  now drives the verdict live.

What's inside

• A complete Python node (derivatives/netnode/, 74 tests) and an independent Rust node
  (derivatives/validator-rs/, 30 tests), cross‑checked byte‑for‑byte, for both chains.
• Full consensus + transport (validation, mempool, wallet, RPC, DNS seed; hardened wire,
  crash‑safe persistence, TCP block‑sync, tx relay, mining), the build‑reconstruction module, and
  the operator docs
  (ANNOUNCE ·
  RELEASE_SIGNING).
• scripts/reproduce.py re‑runs the Python lab (22/22); scripts/verify_genesis.py re‑derives
  both genesis blocks from source.

Verify this release

# 1. import the maintainer's key + confirm the fingerprint out of band
gpg --import genesis/docs/parthod0x-signing-key.asc
gpg --fingerprint B0145F74B78CF1DA
#   must be:  B128 526A F85A E4A8 F22B  949F B014 5F74 B78C F1DA

# 2. verify the archive + checksums
gpg --verify obl-genesis-0.4.0.tar.gz.asc obl-genesis-0.4.0.tar.gz
gpg --verify SHA256SUMS.asc SHA256SUMS && sha256sum -c SHA256SUMS
#   sha256: 08794bb63805f751eabcb2026e2c96de6cb81570027e87603e8423945f76dfb6

# 3. verify the content itself — the part that truly matters
python scripts/verify_genesis.py                 # both genesis blocks re-derive from source
python scripts/reproduce.py                       # expect: ALL PASSED, 22/22
cd derivatives/validator-rs && cargo test         # expect: 30 passed

A valid signature proves the build came from the maintainer and is unmodified — that is all. It
does not make this money or "the real Bitcoin"; nothing does. The durable guarantee isn't the
signature, it's the reproducible recipe (verify_genesis), which lets anyone re‑derive the exact
genesis, with no key and no node to trust.

Not money.