Methodology & Changelog
How the lab's tools are built, what they do and don't do, and how they evolve.
Bitcoin Quantum Exposure Tester
Approach
Heuristic public-key exposure analysis. The tester checks on-chain spending history as a proxy for public key visibility — the primary attack surface for a future quantum adversary.
- Data source — Blockstream public API, queried entirely client-side. No server intermediary.
- Address types — P2PKH (1...), P2SH (3...), P2WPKH (bc1q...), P2TR (bc1p...).
- What it checks — on-chain spending history as a proxy for public key visibility. An address that has been spent from has had its public key broadcast to the network and recorded permanently on the blockchain.
Known Limitations
- Does not detect multisig configurations or spending conditions
- Does not perform change clustering or full transaction graph analysis
- Does not detect script-path Taproot spends
- Results reflect on-chain state at time of query — not a live mempool scan
Privacy
No addresses are stored or logged. All queries go directly from the user's browser to Blockstream's public API. The lab never sees, records, or transmits the addresses you check.
Why Heuristic Language
The tool uses phrases like "may indicate" and "suggests" because on-chain spending patterns are a proxy for key exposure, not a definitive proof of vulnerability. A spent-from address strongly correlates with public key visibility, but the tool does not perform cryptographic verification of the actual transaction witness data. Heuristic language reflects this honest limitation.
Defense Checklist
Approach
Guided self-assessment that branches by audience (individual or organization), with questions covering address hygiene, key management, wallet configuration, and migration readiness.
- Scoring — lightweight readiness bands based on yes / somewhat / no responses. Each answer contributes to a composite score that places the user in a readiness tier.
- Storage — local browser only (localStorage with 7-day expiry). No data is sent to any server.
Why Not a Formal Audit
The checklist helps users orient themselves and identify obvious gaps. It is not a compliance tool, certification, or complete risk assessment. It produces a directional readiness signal, not a security guarantee.
Action Plan Design
Results produce immediate / near-term / longer-term action tiers, each linked to relevant research pages on this site. The tiering is designed to help users prioritize: address the highest-impact gaps first, then build toward a more complete posture over time.
Why the Tools Use Heuristic Language
The Exposure Tester says "may indicate" and "suggests" rather than "confirms" or "proves." That is intentional. On-chain spending patterns are a strong proxy for public key exposure, but they are not proof of vulnerability — quantum attacks depend on hardware that does not yet exist, and the relationship between key visibility and practical risk varies by address type. Stating results as indicators rather than verdicts respects both the user's intelligence and the limits of the analysis.
Why the Checklist Branches by Audience
An individual managing a Ledger wallet faces different quantum preparation questions than a CISO evaluating enterprise key governance. The checklist branches at the start because generic one-size-fits-all assessments produce generic results. The trade-off is a slightly longer setup step in exchange for significantly more relevant output.
Why Everything Runs Client-Side
The tester queries Blockstream's public API directly from the user's browser. The checklist stores progress in localStorage only. No addresses, responses, or results are transmitted to our servers. This is a deliberate privacy-first design choice — users assessing their own quantum exposure should not have to trust a third party with the data they are trying to protect.
Why the Site Practices Crypto-Agility
The site itself is built as a static property with minimal dependencies, no tracking pixels, no third-party analytics, and no framework lock-in. That is not just a hosting preference — it reflects the same principle the research advocates: systems should be designed so they can evolve without rebuilding from scratch.
From Ambiguity to Action
The site is designed around a single progression: moving users from vague awareness of quantum risk to concrete next steps. Each layer builds on the previous one.
Each tool in the lab exists to move users one step further along this path. The goal is not to alarm — it is to reduce the distance between "I should probably look into this" and "I know what to do next."
Changelog
Version History
- April 2026 — v1.1 — Tester: methodology block, Taproot-specific language, print results, "means / does not mean" panel
- April 2026 — v1.1 — Checklist: local save/resume, stronger result bands, category context, version footer
- April 2026 — v1.0 — Initial release of Bitcoin Quantum Exposure Tester
- April 2026 — v1.0 — Initial release of Defense Checklist
- April 2026 — v1.0 — Bitcoin Quantum Defense Brief published
- April 2026 — Signals publication layer launched (5 initial notes)
- April 2026 — Site launch: 8 research pages, About, Contact, Privacy
XRP Certified Mail Experimental
Alongside the main Bitcoin and post-quantum migration work on this site, this lab has also explored a side prototype on XRPL focused on tamper-evident message receipt proofs.
The goal of that experiment is not to present a production-ready messaging system, but to test how crypto-agile trust layers might be added around message integrity in a future where classical signature assumptions become less stable.
It includes an experimental server-side "Quantum Shield" layer — a hash-chain proof mechanism that does not depend on ECDSA — and is best understood as a prototype for research and design exploration.
This is an experimental side project and is not part of the site's primary Bitcoin / post-quantum migration resource path.
Use the Tools
Check your exposure and assess your readiness.