Bitcoin Quantum Exposure

What the audit found

The audit covered the analysis scripts, PostgreSQL tables, external ingestion handoff, enrichment, publication, and browser calculations. The following findings describe the legacy pipeline at the audited revision. Reproductions demonstrate specific defects; source risks identify possible failures without establishing their frequency in production.

The complete dated audit retains all 25 findings, source references, evidence, and reproduction commands.

Accounting and interpretation

• Details and aggregates disagree. Group-wide balance and activity filters in detailed rows differ from per-script filters in aggregates. At block 961,000, the compared detail rows sum to 690,310,766,949,019 satoshis and 7,691,828 UTXOs; the ge1/All/all aggregate reports 690,303,223,537,713 satoshis and 7,562,231 UTXOs. That is a discrepancy of 75.43411306 BTC and 129,597 UTXOs, not a verified correction to the total exposed supply.
• Some historical dates were fabricated by a sentinel. Unresolved script-hash spends were assigned height 1 and then its timestamp. At block 850,000 this affects 3,354 rows holding 43,196.90884687 BTC; at 500,000, 387 rows holding 15,708.22053099 BTC. Those dates cannot substantiate exact spend times or adjustable inactivity filters.
• Funding and disclosure were conflated. A balance could appear exposed from its funding date even if its key became known much later. First funding, first disclosure, and first exposed balance need separate evidence.
• A reporting group is not a unique cryptographic key or owner. Address/keyhash grouping does not globally deduplicate curve points. A spent script-hash address is a heuristic, not proof of a usable quantum spending path for every policy. Key disclosures, validated script commitments, recognized spending paths, and unsupported policies must remain distinct.
• Multisig parsing was too permissive. Isolated fixtures accepted missing, undersized, or invalid keys. Cached negative labels could also persist. The reproduction establishes a parser defect, not its prevalence in Bitcoin data.
• Migration estimates need explicit scenarios. Input counts, script assumptions, serialized transaction weight, and feasible transaction sizes were not one consistent versioned model. A chosen packing scenario does not establish an unconditional lower bound.
• Addressless bare multisig may be omitted. Builders required an address even where downstream code supported outpoint identity. The audit did not quantify the incidence or resulting undercount.

Source consistency, recovery, and publication

• A maximum source height does not certify completed ingestion. Committed spends can still await archive movement. Independent reads may see different source states, and source reorgs did not invalidate all Quantum checkpoints.
• Lagged reconstruction can miss outputs. Looking only in the newest spent-output archive is insufficient when the target is far behind the source or crosses an archive boundary.
• A failed release could be skipped. A full CSV in a directory could advance the next target before enrichment, validation, and both deliveries completed. Destination retries lacked an independent durable ledger.
• Archive merging dropped rows. Adding the first archived row made later rows for the same snapshot look duplicate. A fixture retained only one of two archived rows. This affected archive-capable distributions; public Pages intentionally omits those archives.
• Identity inputs were duplicated. Recursive root and archive scans found 121 input files but only 71 unique files; all 50 archived copies were counted twice. Historical copies of a label are not independent attribution evidence.
• Artifact coverage and runtime copying were incomplete. Manifests did not identify every required payload, and standalone copies could omit dependencies. Browser shape checks alone could accept stale values of the correct shape.
• Output isolation and job ownership were incomplete. A historical helper could use the default output root despite an override. Some required helper failures were swallowed, and orchestration lacked a durable single-writer run identity.
• Archive/build transitions did unnecessary work. Moving old directories before finishing catalogs could invalidate selected URLs; copying everything before public pruning also added work.

Why processing was expensive

• Changed groups repeatedly had their entire historical output sets deleted and reinserted. Historical analysis rebuilt and indexed a large temporary world for each requested snapshot.
• Routine diagnostic counts scanned large tables. Several heavy branches ran concurrently, multiplying I/O, temporary work, and memory pressure.
• Enrichment repeatedly scanned old CSV copies and materialized full datasets. The P2PK cache’s writes could roll back when the current analysis connection closed.
• Schema provisioning depended on manually seeded state and indexes that were not fully reproduced in source.
• Detail expansion loaded a whole-chain height/time lookup despite already exported timestamps. The original lookup was about 18.2 MB, alongside a 24.1 MB detail CSV; the compact top-100 payload was only about 14 KB.

At the original inspection, legacy derived tables occupied approximately 1,713 GiB in addition to the source database. The dominant problem was repeated database and data-processing work. A wholesale translation from Python to Rust or C++ would not remove that work.

The redesign and its limits

The chosen approach retained Python and PostgreSQL: reuse source facts, keep compact group and disclosure state, process bounded changes, and stream all export views from one consistent calculation. A separate worker would discover confirmed 1,000-block boundaries and retry publication independently.

The implementation source was deployed, but deployment of source is not acceptance of its analytical output. The draft logical warehouse schema remains a proposal; it was not blindly applied as a second wholesale copy of the source database.

The initial methodology retained canonical-chain disclosure semantics and explicitly separated legacy script-address heuristics from verified evidence. Broader historical key coverage and orphan-observed disclosure would require separate methodology versions and validation. Unknown first exposed-balance dates remain unknown.

What was actually measured

Measurements came from bounded initialization on an Apple M4 Max with 128 GiB of RAM and PostgreSQL 14. The one-time faster profile used one heavy writer, no parallel query workers, batches of up to one million occurrences, five-minute slices, 256 MiB session work memory, and an 8 GiB combined worker/backend private-memory guard. A 512 GiB free-disk reserve remained in place.

The proposed unattended targets—30 minutes of active processing per boundary and 4 GiB of private memory—were not established. Faster seeding did not demonstrate that a complete interval, export, validation, and publication would meet those targets.

Selected real-source replay fixtures covered 6,232 output lifetimes from three windows, with 42 sampled-state comparisons and six endpoint artifacts per window. They were bounded samples, not complete historical intervals, and contained no multifamily groups. They do not establish full high-churn, disclosure-fanout, or archive-rollover coverage.

A final synthetic multi-snapshot test was unfinished: its independent oracle passed, but its first real-PostgreSQL snapshot assertion failed because the request remained analyzed rather than complete. It did not prove three-generation replay. The source is retained and clearly labeled unfinished.

The preserved stopping point

The maintainer requested archival while the historical initialization was running. The supervisor stopped at 01:52:38 UTC on October 6, 2026 (October 5 locally). Its child process and PostgreSQL backend were verified absent. Processing remains paused.

• Published dashboard: legacy snapshot 961,000 and its existing available history, preserved without fabricated publication markers.
• New projection: 262,192,306 occurrences committed; initialization cursor at height 378,478 against canonical anchor 962,000. A cursor is progress through seeding, not a completed snapshot at that height.
• Interrupted attempt: its durable record still says running, with no completion metrics. The process is gone. The record was retained without rewriting it as successful.
• Recovery material: checkpoints, additive tables, source and retention data, implementation commits, manifests, and private operational evidence remain preserved. No old source or derived tables were removed for archival.

Public Pages continues to omit raw/archive-only data by design. Existing local and archive-capable distributions retain their distinct data coverage. Archiving this dashboard does not stop WSB’s other dashboards or block ingestion.

Any future restart needs a new decision to resume, inspection of current source identity and checkpoints, recovery of the interrupted attempt, and completion of the outstanding correctness, resource, publication, and rollback checks. This archive does not authorize an automatic restart.

Technical record

The public record preserves the audit and reproducible source. Machine-specific logs, configuration, credential context, and raw operational evidence are retained privately.

• Original audit, all findings, evidence, and reproduction scripts — a dated record based on revision 39f288a9.
• Redesign and deferred logical schema — proposed architecture and its validation requirements.
• Preserved implementation — deployed source integration e53a94c6, including implementation through 87711822.
• Operating guide and archive status — retained instructions, with operation paused.
• Unfinished multi-snapshot test — preserved source and the failed verification status.