[Research] Bitcoin Time Machine: v0.01-v0.10 with Nix & bitcoinkernel

[Research/Dev] Bitcoin Time Machine: Compiling v0.01 to v0.10 Natively on Modern Linux with Nix & Bridging to libbitcoinkernel

Hello Bitcointalk community,

Over the past few weeks, we set out to solve a long-standing challenge in Bitcoin software archaeology: compiling and running early Bitcoin clients (from Satoshi's v0.01/v0.1 ALPHA up to v0.8.0, v0.9.3, and v0.10.4) natively on modern Linux systems (bare-metal, no slow legacy VMs, no bloated Docker images), and auditing their historical block databases directly against Bitcoin Core's next-generation consensus engine: libbitcoinkernel.

We wanted to share the reproducible declarative environment we built, how it solves 15+ years of software "bitrot", several fascinating protocol quirks unearthed from the raw blocks, and the open-source repository so anyone can reproduce it in seconds.

---

1. The "Bitrot" Problem: Why 2009–2015 Nodes Fail on Modern Linux

Attempting to build these clients on a modern Linux distribution (Ubuntu 22.04/24.04, Arch, Fedora) with modern glibc (2.38+) and GCC 12/13+ leads to instant failure:
1. OpenSSL 3.x API Breaches: Early Satoshi and Core releases depended intimately on OpenSSL internals for BIGNUM arithmetic, ECDSA operations, and hashing structures. Modern OpenSSL 3.x deprecates or completely drops these C interfaces.
2. Berkeley DB [BDB 4.8] Bitrot: Essential for legacy wallet storage and pre-LevelDB block indices. Compiling BDB 4.8 on modern toolchains fails due to incompatible POSIX mutex definitions and strict non-permissive C++ standards.
3. Language Evolution [C++98 to C++20]: Deprecated typedefs, non-narrowing conversions, and raw Boost threading models trigger fatal compiler errors under modern compilers without specific fallback toolchains.
4. GUI Display Server Drift [X11 to Wayland / Hyprland]: Legacy wxWidgets 2.8 and early Qt4/Qt5 interfaces crash looking for missing X11 display plugins.

---

2. The Declarative Solution: Pinned Toolchains via Nix

Rather than spinning up old Ubuntu 10.04 virtual machines, we used Nix to isolate and pin mathematically reproducible toolchains directly on modern bare-metal Linux.

Each version directory has its own dedicated 'shell.nix' with exact cryptographic dependencies:
- v0.01 / v0.1 ALPHA: Pinned GCC, Berkeley DB 4.8, OpenSSL, wxWidgets, and Qt5/Wayland platform wrappers.
- v0.8.0: Pinned Boost 1.77, BDB 4.8, OpenSSL, LevelDB integration.
- v0.9.3 & v0.10.4: Pinned OpenSSL 1.1.1w ('permittedInsecurePackages'), Boost, BDB 4.8, and Qt5 Wayland plugin paths ('QT_PLUGIN_PATH' and 'QT_QPA_PLATFORM_PLUGIN_PATH').

Entering any version directory and running 'nix-shell shell.nix' provides an instant, isolated historical environment where running 'make' or './configure' builds cleanly in seconds.

---

3. Archaeological Discoveries & Historical Consensus Quirks

While inspecting the raw 'blk0001.dat' files produced by our running nodes:

• Pre-BIP-34 Coinbase Scripts & TXID Collisions:
In clients prior to v0.8 / BIP-34, miners were allowed to serialize arbitrary data or nonces into the coinbase 'scriptSig'. There was zero enforcement of block height! This famously caused Blocks #91,812 and #91,842 to have identical coinbase transactions, overwriting earlier unspent outputs until BIP-30 and BIP-34 permanently enforced serializing 'CScriptNum(height)' as the first script element. In our generated blocks, we observed raw nonces and unpadded text (like Satoshi’s famous The Times 03/Jan/2009 headline) filling the coinbase script without height markers.

• The Berkeley DB vs LevelDB Hard Fork (March 2013 Incident):
Bitcoin v0.8.0 marked the historic transition from Berkeley DB ('blkindex.dat') to Google's LevelDB. BDB had hardcoded limits on simultaneous locks. When miners upgraded to v0.8, a block with thousands of inputs was mined: v0.8 accepted it smoothly, but older v0.7 nodes locked up inside BDB, creating an accidental consensus fork. Running v0.8 with both engines available side-by-side in Nix allows reproducing and studying this divergence deterministically.

• The Dominance of P2PK:
Every block inspected in the early chain mined rewards directly to 65-byte uncompressed public keys (0x41 0x04... 0xac OP_CHECKSIG). Pay-to-PubKey-Hash (P2PKH '1...' addresses) was virtually absent from early coinbase generation.

---

4. The Modern Bridge: Auditing History with libbitcoinkernel (py-bitcoinkernel)

To connect 2009 with modern protocol research, we built a Python auditing harness utilizing the official libbitcoinkernel C++ consensus engine bindings ('py-bitcoinkernel' / 'pbk').

Without running any full 'bitcoind' daemons, our script:
1. Ingests raw blocks directly from 'blk0001.dat' into an isolated C++ 'ChainstateManager' in 0.044 seconds.
2. Verifies the Genesis block anchor (#0) and connects Block #1 with full Proof-of-Work validation, advancing the active chain tip.
3. Tests strict chain continuity by attempting to connect an orphan block (Block 281), confirming the C++ kernel immediately catches and rejects missing parent links ('BLOCK_RESULT_MISSING_PREV').
4. Evaluates transaction scripts against the soft-fork timeline via 'ScriptVerificationFlags':
- v0.1 (Satoshi Era): NONE (0x0)
- v0.6 (BIP-16): P2SH (0x1)
- v0.10 (BIP-66): P2SH | DERSIG (0x5)
- v0.12 (BIP-65 & BIP-112): CLTV | CSV (0x605)
- v0.13.1 (BIP-141): WITNESS (0x805)
- Bitcoin Core Modern (BIP-341): TAPROOT / ALL (0x20e15)

---

5. Open Source Repository & Quick Reproduction

The entire setup—including the 'shell.nix' recipes, Wayland launch wrappers, sample block fixtures, and the 'py-bitcoinkernel' consensus audit suite—is fully open-sourced on GitHub:

🔗 GitHub Repository: https://github.com/rorupuntou/bitcoin-archaeology-kernel-bridge

How to test the consensus audit in 10 seconds:

Code:

git clone https://github.com/rorupuntou/bitcoin-archaeology-kernel-bridge
cd bitcoin-archaeology-kernel-bridge

# Run the 40ms kernel block ingestion audit:
uv run --with py-bitcoinkernel python3 historical_kernel_auditor.py

# Run the BIP consensus rules matrix test:
uv run --with py-bitcoinkernel python3 test_bip_consensus_rules.py

We would love to hear thoughts, feedback, and questions from fellow protocol researchers, historians, and node operators!