Reviving early Bitcoin from source + a full history with the original authors

Hi all,

I've been working on preserving and actually reviving the earliest Bitcoin code, and I wanted to share three repositories. Everything compiles, runs, and finds peers again — and the full Git history is reconstructed with the real author identities.

1) bitcoin-history — compilable rebuilds of the earliest releases
https://github.com/Kino1994/bitcoin-history

This preserves and revives Satoshi's November 2008 preview plus the official v0.1.0 and v0.1.3 releases — not just archived, but rebuilt from source with a period toolchain so they run today.

What's inside:

bitcoin-nov08/ — Satoshi's Nov-2008 pre-release preview (incomplete, doesn't compile standalone)
bitcoin-nov08-rebuild/ — a compilable wxWidgets GUI reconstruction with byte-exact consensus/genesis
bitcoin-0.1.0/ and bitcoin-0.1.3/ — original source + binaries (Jan/Mar 2009)
irc/ — rebuilt 0.1.x clients that find peers again (via the still-alive LFnet network)
toolchain/ — period stack (wxWidgets 2.8.12, Berkeley DB 4.8, Boost, OpenSSL 0.9.

The two fixes that make them work again:

Peer/IP discovery: the original 0.1.x clients call GetMyExternalIP against hard-coded 2008 IP-echo addresses that are long dead, causing multi-minute timeouts. The patched builds resolve those services by domain name instead.
IRC bootstrap: modern IRC servers require \r\n line endings instead of the bare \r the old client sent. The rebuild fixes the five line terminators and adds domain-based server resolution.

Build is straightforward:

Code:

toolchain/build-toolchain.sh                       # one-time, ~15 min
cd bitcoin-0.1.0/src && ../../toolchain/make.sh    # Satoshi's own makefile
# IRC client (LFnet build — this one actually finds peers):
cd irc/lfnet/bitcoin-0.1.0 && wine ./bitcoin.exe

Everything except the raw nov08 preview compiles from source; cross-compiles on Linux and builds natively on Windows.

A note on IRC peer discovery — LFnet vs Freenode
Bitcoin 0.1.x bootstraps over IRC: each node sets its own nickname to its base58-encoded address, then does a WHO to decode everyone else's. There are two builds:

irc/lfnet/ (irc.lfnet.org) — works. LFnet is still alive, still hosts #bitcoin, and still has real nodes advertising. You really see lines like GOT WHO: [...] new CAddress(158.140.180.83:8333).
irc/freenode/ (chat.freenode.net) — connects and joins, but cannot discover peers. Freenode's anti-spam Z-lines any nickname shaped like a base58 address, so the act of advertising itself is blocked. The freenode build therefore falls back to an addressless x<digits> nick (which registers and can mine with a supplied peer, but can't advertise). A WHO of #bitcoin there returns ~77 people, not nodes.

The "n trick" doesn't help — the ban is by shape, not prefix. We tested advertising with an n<base58check> nick instead of u<base58check>, on one clean IP: the x<digits> client stayed connected and mined 4 blocks, while the n<base58check> nick registered, JOINed, and was Z-lined ~1 second after the JOIN. So a different prefix only delays the ban to just after JOIN; it never evades it. Freenode's filter targets the base58-address shape (a letter + a long mixed-case blob), not the u character.

Important — this is a policy limit, not a protocol one. The client and the 2009 IRC bootstrap are fully capable of advertising and discovering on Freenode; the only remaining blocker is that anti-spam rule. If Freenode lifted it — or you point the same build at any network that permits the advertisement nick (LFnet today, or a private/self-hosted IRC server you control) — the u<base58check> advertise-and-discover path lights up unchanged. So if anyone wants to revive the legacy IRC bootstrap, nothing in the client needs further repair: you just need a host network whose policy allows the address nick.

Patches & reproducibility — originals stay pristine
Nothing is edited into the historical source. The fixes live as standalone diffs in patches/, so the rebuilds are reproducible and the originals stay untouched:

patches/code/ — version-to-version source diffs, applied with -p1 onto a copy of the "from" tree.
A separate set of compilation patches handles modern library/compiler compatibility — every difference is in the toolchain around the code, not the code itself.

Concretely:

bitcoin-nov08/ is kept exactly as the original Nov-2008 preview — the compilable reconstruction lives separately in bitcoin-nov08-rebuild/, the original is never modified.
bitcoin-0.1.0/src and bitcoin-0.1.3/src are kept exactly as Satoshi shipped them, his makefile included.
The original Windows binaries are committed as-is. A rebuild only replaces them in the working tree (git update-index --skip-worktree), so a recompile never overwrites or commits over Satoshi's originals.
Honest caveat: because the compiler differs, a rebuilt .exe is not byte-identical to Satoshi's 2009 binary — that's exactly why the originals are kept committed alongside the rebuilds. The source and genesis/consensus are byte-exact; the machine code is reproducible only within the specified period toolchain.

2) bitcoin-full-history — the complete history with the original authors
https://github.com/Kino1994/bitcoin-full-history

This is the full bitcoin/bitcoin history (~49k commits) prepended with the early eras: the Nov-2008 preview, 0.1.0 and 0.1.3, and the SourceForge SVN era stitched onto the front.

Key points:

Real author identities restored: the SVN/SourceForge period normally shows up as user@<UUID>. Here the original names and emails are used, and the original SVN revision identifiers (rX) are preserved in the commits so attribution stays traceable.
It's synced from SVN and from the GitHub repo. Note that SVN diverged for a while — at one point both versions existed in parallel — so the line that kept advancing in SVN lives in the svn-full branch.

3) bitcoin-full-history-sync — how it stays current without rewriting history
https://github.com/Kino1994/bitcoin-full-history-sync

The hard part of a fork with a rewritten base is keeping it up to date with upstream without ever touching the published history. This does it with a deterministic re-splice using git replace (graft) + git-filter-repo — it doesn't merge content, it only rewrites the parent pointers of the old era onto the rebuilt commits. Result:

0 conflicts (no content merge)
preserves author, committer and the exact merge topology of upstream
deterministic — already-published SHAs don't change, so pushes are fast-forwards

Ships as a standalone script (cron-friendly) and a GitHub Actions workflow for weekly auto-sync.

Full disclosure: a huge amount of this was done with Claude Code — it basically did most of the heavy lifting (the toolchain reconstruction, the IRC/IP patches, and especially the graft-based sync) and helped me enormously throughout.

Feedback, corrections, and missing historical pieces are very welcome.