Bitcoin Quantum Preparedness Dashboard

Change category

01 / Weekly change summary

Since last week

The primary view of the record. Every entry states what changed, why it matters, and the prior and current state.

Why it matters

It turns an earlier scaling idea into a reviewable protocol-design agenda for the blockspace and relay costs of future post-quantum signatures.

Previous state

SNARK or STARK aggregation had been discussed and benchmarked in narrower contexts, without a consolidated Bitcoin design thread covering the main architectural choices.

Current state

This is an early design discussion—not a BIP, implementation, benchmarked Bitcoin construction or deployment plan. The author explicitly identifies major open engineering and consensus questions.

Primary sourceDelving Bitcoin design thread

02 / Protocol & BIP tracker

Protocol work

Descriptive status only. Transitions are shown against the prior weekly snapshot.

Latest activity

A 4 September review merge typed every reference value, corrected annotations and signature-size wording, clarified exact arithmetic and added regression checks.

Dependencies

A separate BIP for Bitcoin Script and output integration; peer review, security proof, tests and optimized implementations.

Open technical questions

Parameter choices, state management, wallet backup and recovery, multisignature workflows and implementation hardening.

Governance questions

The draft is not yet submitted to the BIPs repository and has no assigned number, consensus change or activation process.

Contributors

Conduition, Ethan Heilman, Mikhail Kudinov, Oleksandr Kurbatov, Jonas Nick, remix7531 and collaborators.

Last verified

6 Sep 2026

Primary source

03 / Preparedness record

Trackers & evidence

The maintained current state is the default. Weekly change is a secondary evidence layer, never a replacement for the baseline.

Current view

Engineering

All known current activity, including items that did not change this week.

Hash-based · statelessSLH-DSA / SPHINCS-family pathsResearch, benchmarking and wallet-tool prototyping

Current state

Current status

Research, benchmarking and wallet-tool prototyping

Current documented activity

Developers are comparing validation cost with bandwidth and storage impact while an independent backup-format prototype explores operational seed recovery.

Existing evidence

Public parameter analysis, verifier implementations and a working offline backup prototype exist; there is no Bitcoin consensus deployment.

Outstanding questions

Signature parameters, witness pricing, wallet derivation, backup interoperability, multisignature and hardware-device flows remain open.

Last verified

6 Sep 2026

Change since last week

No separate material change located this week; the maintained research and wallet-tool baseline remains current.

Bitcoin integration: Proposed script opcode or leaf path, with separate witness treatment under discussion.
Signature & proof characteristics: Stateless signatures; direct signatures are large, while proof aggregation is an active research path.
Transactions, blockspace & fees: Review weighs validation cost against relay, storage and initial-block-download pressure.
Multisignature & hardware wallets: Composition and device verification flows remain design questions; no wallet deployment located.
Key generation & recovery: A revised independent single-address backup prototype exists, but no shared wallet standard has been proposed as a BIP.
Implementation evidence: Technical reports, verifier work and a wallet-backup prototype; no Bitcoin consensus deployment.

Open primary source

Hash-based · semi-stateful · SHRINCS Working GroupSHRINCS / OP_CHECKSHRINCSDraft cryptographic BIP · executable reference code

Current state

Current status

Draft cryptographic BIP · executable reference code

Current documented activity

Peer review is actively tightening the normative draft and executable Python reference code; Bitcoin Script integration remains explicitly deferred to a separate BIP.

Existing evidence

The public draft now carries explicit size annotations throughout the reference implementation and focused tests for corrected cases, alongside earlier C, Simplicity and Liquid evidence.

Outstanding questions

Full security proof, comprehensive vectors and tests, optimized implementation, state management, wallet recovery and Bitcoin consensus integration remain incomplete.

Last verified

6 Sep 2026

Change since last week

Meaningful update: the 4 September review merge typed every reference value, corrected signature-size and chain-index annotations, clarified exact arithmetic and added regression checks.

Bitcoin integration: The draft specifies SHRINCS cryptography only. A separate BIP would be required for a Script opcode, output construction and consensus deployment.
Signature & proof characteristics: Hash-based design with a stateful primary component and a stateless fallback.
Transactions, blockspace & fees: Parameter and witness-cost choices remain subjects for review; no consensus resource rules are specified here.
Multisignature & hardware wallets: Wallet state, backup, recovery and multi-party use remain early design work.
Key generation & recovery: State reuse must be prevented; loss or uncertainty of state forces use of the stateless fallback.
Implementation evidence: Executable Python code, explicit size annotations and focused regression checks are public; the repository remains experimental and not for production.

Open primary source

Blockstream Research · Falcon, Dilithium and Hawk · 26 Aug 2026Lattice-based signature candidatesBitcoin-specific comparative research · no deployment proposal

Current state

Current status

Bitcoin-specific comparative research · no deployment proposal

Current documented activity

Researchers are evaluating Falcon’s compact signatures and fast integer-only verification against signing complexity, hardware-wallet memory and the absence of workable BIP 32-style public-key derivation.

Existing evidence

A full preprint provides algorithm descriptions, parameter comparisons, security analysis and Bitcoin deployment criteria; separate Ledger SDK work demonstrates constrained-device ML-DSA implementation.

Outstanding questions

FN-DSA standardization, public-key derivation, constant-time and reproducible signing, hardware-wallet performance, independent cryptanalysis and any Bitcoin opcode or output integration remain open.

Last verified

6 Sep 2026

Change since last week

No material change located this week; the 26 August comparison remains the current research baseline.

Bitcoin integration: No BIP, opcode, Bitcoin Core implementation or activation path is proposed. The report evaluates candidate primitives for possible future integration.
Signature & proof characteristics: Blockstream favors Falcon-1024 among the lattice candidates for its size, verification speed and mature assumptions; Hawk was withdrawn after a key-recovery result, while Dilithium is simpler but substantially larger.
Transactions, blockspace & fees: Falcon-1024 combines a 1,793-byte public key with a 1,280-byte signature; still far larger than today’s 96-byte Schnorr key-plus-signature footprint.
Multisignature & hardware wallets: Lattice structure may support future threshold and multisignatures, but no practical construction is ready; Falcon-1024 signing also creates constrained-device memory and performance trade-offs.
Key generation & recovery: No workable BIP 32-style public-key derivation is known for Falcon. Dilithium derivation variants remain proof-of-concept work.
Editorial assessment: This advances protocol research, not protocol readiness: the authors retain hash-based signatures as the conservative near-term option for Bitcoin.

Open primary source

04 / Weekly archive

Snapshots, preserved

Completed weekly summaries are retained at permanent pages so changes remain auditable.

Latest · complete31 AUG–06 SEP 2026Published 7 Sep Previous24–30 AUG 2026Published 31 Aug Earlier17–23 AUG 2026Published 24 Aug