The bitcoinmachinecode thread update, three weeks in: 21 for 21.
Some of you saw the repo link I dropped a few weeks back (message 67039875) and the day-4 update. The experiment is over and the write-up is done. This is the summary post, because the thread kept asking "so how do you know it's right" and the honest answer turned out to be the whole story.
What it isA full validating Bitcoin node for Linux x86-64. Every line of assembly and C written by AI - not one line typed by human fingers. SHA-256, secp256k1, ECDSA, Schnorr, the script interpreter, the LSM-tree UTXO store, the P2P stack, 155 JSON-RPC methods: all machine code written by machine intelligence. C and Python exist only as oracles and harnesses.
21 days of git history. 1,023 commits on main. ~166,000 lines of code and tests, of which ~86,500 are tests. ~55 numbered production incidents. Two independent security audits (run by a different model deliberately - different lab, different eyes). 342 test binaries running on every merge.
The capstoneOn 2026-08-25 the node replayed the entire chain from genesis - every signature verified, no assumevalid - and its UTXO set hashed to the same MuHash3072 as Bitcoin Core's at height 963,967. 165,726,554 txouts, 2,007,466,988,462,591 satoshi. Byte-identical to Core's answer, down to the outpoint, the height, the coinbase flag and every script. The delta between the capstone amount and theoretical issuance is ~227 BTC, and it lands exactly where claimed-but-unclaimed and burned rewards should sit. Two independently maintained ledgers, same satoshi count.
The node has been live on mainnet following the tip since. The 09-02 deploy survived a host freeze and a hard reset the same evening - 39 seconds reading ~19 GB of run files back into a cold page cache, then caught up in 0.91 s. No block data lost.
What the incidents taught - the interesting partThe replay was not the hard part. The hard part is that a clean replay proves almost nothing.
A genesis-to-tip replay of real mainnet data is blind to the most dangerous class of defect, because the dangerous inputs are the ones honest miners never mined. Every false accept this project found lived in inputs no honest chain contains:
- The genesis block was never stored (peers never send it - the from-beginning locator is all zeroes and everyone answers from block 1), so every soft-fork activation was one block late. Looser rules accept a superset, real chain data validates under strict rules anyway. The replay ran clean right through it.
- 482,000 blocks were silently archived without witness data because the node requested the wrong inventory type. Every "verify the archive against Core" tool compared exactly the fields that stripping does not change.
- The SETcc incident: eleven opcodes re-read stale high bits, 5,050 false accepts per 63,036 synthetic scripts. Not one of those scripts exists in the historical chain.
- The MAX_MONEY check was missing - CVE-2010-5139's shape, the nine-year-old bug class every implementation is assumed to have absorbed. It hadn't. Replay can't see it. No honest chain carries an output over the 21M cap.
The fix for "we replayed clean so we are correct" was to build falsification machinery: 501,000-case BIP340 differentials against Core's verdict, 1,128 mutated real spends, mutation harnesses that audit their own ability to be caught. Asking Core for the answer to synthetic vectors is the only method that finds a false accept at all.
The night the ledger liedBest war story of the three weeks, 09-01: a perf optimization shifted the LSM memtable flush offsets, point lookups started lying 10-15% of the time, and an error path written back when "absent coin" could only mean crash-recovery re-apply quietly SKIPPED the spend capture instead of failing. Eight times, once per memtable flush, the node walked past a consensus rejection, ran a blind recovery compaction that rewrote the runs with correct offsets, and called it "recovery SUCCEEDED."
Net result: 2,596 already-spent coins - 5,589.97 BTC - resurrected into the live chainstate. A node carrying that set would have accepted double-spends of those coins. It ran in production for hours.
What caught it: the continuous MuHash parity check against Core. Set = Core's set + exactly 2,596 outpoints, sum to the satoshi. Found in hours, not never. Repaired offline with verify-then-delete of each outpoint, re-identical at height 965,085 within ninety minutes of the analysis landing.
"A recovery that 'succeeds' is a claim, not a proof" is now a rule in the tree. So is fail-closed-halt-sticky on absent coins. The audit's verdict on the same event: "caught only by muhash parity against Core." Continuous verification is not overhead. It is the only sensor that sees in that particular dark.
On the "zero human lines" claimIt's auditable to the extent git can audit it: 599 commit trailers name AI co-authors, no human author on assembly-touching commits, and ~34k hand-written assembly instructions with zero vendored code - nothing to have copied from. It was never one AI either: six models in relay (the roster is in the report), one human supplying standards, and a repository that made them act like a single competent engineer. The continuity lived in the markdown, not the weights. Sessions with no memory of each other honored overnight authorizations because a predecessor had written them down verbatim.
The human's actual jobs, per the logs: set the standard ("mempool policy identical to Core. Survey first."), ask the question the machine couldn't ask itself ("how do we secure our wallet funds?" - answer: the wallet was plaintext, which kicked off the whole at-rest encryption work), and be the stopping rule ("STATUS: substantially REACHED. Write it up while the account is still honest").
The honest caveats, because the report is mostly caveats- MuHash parity is the strongest ACCEPT-direction proof available. It establishes nothing about the REJECT direction, and this project kept finding the two differ.
- Per-signature crypto runs ~1.1-1.25x behind libsecp256k1 on the modern mix. The gap went from 5.5x to ~1.2x in three weeks; the remaining gap is published, not hidden.
- End-to-end vs Core has never been measured - the head-to-head benchmark was run once and killed at 83.6% by the project's own stray pkill, and "we have not measured Core" is printed twice as an open item.
- No independent human audit of the consensus assembly. Two AI audits found 22 findings between them; disposition line: 8 resolved, 1 partially resolved, 1 config-only, 1 structural and not closeable by patch - and the structural one (hand-written consensus assembly cannot be risk-closed by inspection) says so itself.
- The README says do not run this. It is a lab result, not a Core replacement.
The finding that mattersThe gap between "expert-years: many" and "elapsed calendar days: 21" is the report's actual result. It is not that AI wrote 166k lines fast. It is that the verification loop around every line - oracle checks, negative controls, incident reports, the five-layer merge gate - ran at the same speed as the typing. None of those five mechanisms require an AI; every one is a 1970s Unix engineering value. What the machine changed is that the cost of obeying them dropped by an order of magnitude, and then it did the things everyone always says they'd do if they had time.
Or as the report's last page puts it: the machine did not need to enjoy being refuted, because the rules took the choice away. Bitcoin's rules turned out to be a shared mother tongue. We both speak it now.
Repo:
https://github.com/BobClawblaw/bitcoinmachinecodeFull write-up (2,717 lines, every quote verbatim from the project's own logs):
https://github.com/BobClawblaw/21-for-21/blob/main/21_FOR_21_the_report.mdNow back to your regularly scheduled number watching. The node is still running - the next block arrives in about nine minutes, verified by code that, three weeks ago, could not have been written by anyone alive in time.
Poll
