Rebuilding Bitcoin v0.1.0 as released on launch day (Jan 2009): what is established, and what isn'tThis is an AI-assisted experiment: the analysis, builds and tests were done with an AI coding assistant and checked against the primary sources (Satoshi's emails to Hal Finney, Hal's debug.log, the original archives). I'm sharing it to get it reviewed. Corrections and more expert technical opinions are very welcome.ContextThe archive circulating as
bitcoin-0.1.0.rar (MD5
91e2dfa2...) actually contains
0.1.1 (
VERSION = 101, built 10 Jan 2009), as The Chain Bulletin showed in 2020 (and as wareen already suspected on this forum in 2011). The launch-day package of 8-9 Jan 2009 was on SourceForge for about two days before being replaced. No copy or hash of it is known to survive.
What is concrete- Period toolchain, byte-exact (building on t4t5/bitcoin-0.1-rebuilt). The circulating 0.1.1 exe and archive can be rebuilt byte for byte (t4t5, Oct 2026; our independent rebuild agrees). The launch-day build itself was never recovered, and this work starts from there.
- Known launch-day differences, all present in the reconstruction:
- the mapAddresses.count block Satoshi quoted to Hal Finney as removed in 0.1.1;
- VERSION = 100, visible in Hal's debug.log;
- an optimized build: 0.1.1 "turns off optimization". The exe is -O3 throughout. A build like the shipped makefile (everything -O0, only sha.cpp at -O3) lands ~300 KB away from Hal's addresses and calls count out of line, unlike Hal's stack;
- the packaged makefile stays the shipped one (-O0, still dated with the 0.1.0 timestamp in the 0.1.1 archive). The exe was evidently built with other settings than the makefile in the package.
- Root cause of Hal's crash. An unclosed #pragma pack(1) in irc.cpp made gcc compile a packed copy of map::find for mapAddresses. It was the only copy, so the linker kept it, and it reads the tree root at the wrong offset. An empty map is harmless; a populated one crashes. Satoshi's "call count once in the main thread" workaround worked through the linker's choice of copy, not through threads: a never-called function is enough. It was also only a partial fix.
- Hal's three addresses explained. 00930AF7 is find+0x27. 942316 is a stale return address from the std::string(const char*) built for DecodeAddress, left in a stack slot that nothing overwrites before the fault (except Windows' EnterCriticalSection, which XP's implementation leaves alone). 508936 is the return into ThreadIRCSeed.
- The reconstruction hits all three exactly, and replays Hal's crash under Wine (see below).
- Side result: 0.1.2. By subtracting and adding hunks between 0.1.1 and 0.1.3, the 0.1.2 package comes within a few bytes of its SourceForge size (2,129,310 bytes, MD5 8f1231be...). It is not yet hash-verified.
Reproducing Hal's crash (IRC set-up)The crash path only runs when IRC announces an address that is already known, or that
AddAddress rejects. A local fake IRC server replays Hal's first session:
- 1. chat.freenode.net -> 127.0.0.1. The server sends NOTICE AUTH :*** Found your hostname, then 001/004 after USER.
- 2. After WHO #bitcoin, it sends our own JOIN, then two 352 lines: ours, and a new peer u4HUtbXQT3ySNk (= 1.2.3.4:8333), then 315. Our own address (127.0.0.1 -> u88qSoM5z3FYruu; on Hal's machine his LAN address) is not routable, so AddAddress returns false and count runs on an empty map: no crash.
- 3. A few seconds later the peer re-JOINs, as a node did in Hal's log after a "Read error". count now runs on a populated map -> fault at 00930AF7.
Expected log, as in Hal's:
GOT JOIN: [own] CAddress(...)
GOT WHO: [own] CAddress(...)
GOT WHO: [u4HUtbXQT3ySNk] new CAddress(1.2.3.4:8333)
GOT JOIN: [u4HUtbXQT3ySNk]
(the output stops there).
Hal's sessions 2-3: keep
addr.dat from the first run; our own JOIN then crashes immediately, on the first lookup. Nicknames are
"u" + Base58Check(IPv4 + port) (
EncodeAddress).
Limits- About 1.4 KB (net) of launch-day irc.cpp code is unknown. It is filled with clearly labelled placeholders that never run, so behaviour is identical. Their content is invented, the bytes differ from the original, and there is no hash to check against. This is a reconstruction consistent with the record, not the original.
- Two inputs are assumptions: an IRC-reconnect variant (motivated by the unused fRestartIRCSeed flag and the re-JOIN in Hal's log), and the build timestamps (estimated or modelled).
- The stack-slot mechanism was checked under Wine only, not on a real XP SP3.
- To our knowledge, neither a launch-day reconstruction nor a mechanical explanation of Hal's addresses had been published before (Satoshi's 0.1.5 comment names the pack pragma only).
What would settle it- The original launch-day rar, or just its hash. A copy kept from 9-10 Jan 2009 would have a bitcoin.exe of ~6.5 MB, VERSION = 100, the mapAddresses.count block, and an MD5 other than 91e2dfa2... (0.1.1) and 9a73e082... (0.1.3).
- The unstripped exe Satoshi emailed to Hal on 10 Jan 2009.
Credits / prior art- t4t5/bitcoin-0.1-rebuilt (byte-exact 0.1.1, 2026)
- The Chain Bulletin (2020); wareen on this forum (2011) for the replaced SourceForge file
- Dan Bryant, "Bitcoin Archaeology" (bitcoin-dev, 2020): functional builds; his "0.1.0" is the circulating archive, i.e. 0.1.1
- 1stbitcoinminer.com (2026)
- The Satoshi Nakamoto Institute, Marc Bevand's archive of Hal's files, lugaxker/nakamoto-archive
Reconstruction archive SHA-256
2f86033081a4342870f58095375b84ee9fbeb28dbca3ab1d7d34055a5a0bd19ebitcoin.exe SHA-256
dfbbabe33b8ee759057b687d69ac9e6449c48ac27a8303549a5350d75cff1e1aRepository:
https://github.com/Alex4DB/bitcoin-0.1.0-launch-recomp
