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

The comment narrows what the machine-checked proof currently establishes and records the next proof obligations before the C implementation can support a stronger security claim.

Previous state

libshrincs already provided a handwritten C WOTS+C implementation, VST functional-correctness work and SSProve/Rocq game-based proof artifacts.

Current state

The project remains a proof-of-concept toward full SHRINCS, not a production library, completed proof of the whole scheme, Bitcoin Script integration, BIP or deployed capability.

Primary sourcelibshrincs review on Delving Bitcoin

02 / Protocol & BIP tracker

Protocol work

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

Latest activity

A 27 October review of the separate libshrincs WOTS+C proof-of-concept identified a composition gap between the proved known-message experiment and a standard one-time EUF-CMA claim, plus digest-ordering and state-rollback cases. The SHRINCS draft itself did not change status.

Dependencies

A separate BIP for Bitcoin Script and output integration; proof composition, full-scheme coverage, peer review, tests and optimized implementations.

Open technical questions

Parameter choices, proof boundaries, state rollback and key reuse, 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

1 Nov 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.

Localhost Research, Boneh, Bünz and collaborators · 21–27 Sep 2026PRAWNS threshold hash-based signaturesCryptographic preprint · no Bitcoin implementation

Current state

Current status

Cryptographic preprint · no Bitcoin implementation

Current documented activity

The authors are developing threshold functionality for hash-based signatures while keeping coordination and the large-committee lattice assumption on the signer side rather than in Bitcoin’s verification rules.

Existing evidence

A peer-reviewable IACR ePrint preprint and Bitcoin-focused Localhost Research explanation are public; no code, BIP or consensus integration was linked in the cited sources.

Outstanding questions

Efficient distributed key generation, concrete Bitcoin parameters, implementation and audit, state and retry handling, signer coordination and integration with a selected Bitcoin signature path remain open.

Last verified

1 Nov 2026

Change since last week

No material change located this week; the 21–27 September preprint and research announcement remain the current state.

Bitcoin integration: The final signature is intended to use the same verifier as the underlying hash-based signature; no opcode, output type or Bitcoin integration proposal exists.
Signature & proof characteristics: Threshold signing produces a standard non-threshold signature while hiding the participant count and threshold.
Supported constructions: Designed principally for Winternitz, XMSS and FORS-family schemes; the paper says it does not directly apply to SLH-DSA.
Threshold operations: Supports large committees in its lattice-assisted construction and participant or threshold rotation without changing the public key.
Implementation evidence: Preprint and research article only; no reference implementation or deployment evidence was identified.
Known limitation: No efficient distributed key-generation protocol is provided.

Open primary source

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

1 Nov 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 continues around the normative draft and executable Python reference code; Bitcoin Script integration remains explicitly deferred to a separate BIP.

Existing evidence

The public draft 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

1 Nov 2026

Change since last week

No separate material status transition was substantiated this week; the 4 September typed-reference and regression-test merge remains the latest recorded milestone.

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

remix7531 and reviewers · C, VST, SSProve and Rocq · review 27 Oct 2026libshrincs machine-checked WOTS+C proof-of-conceptProof-of-concept · proof boundary under review

Current state

Current status

Proof-of-concept · proof boundary under review

Current documented activity

The project connects a handwritten C WOTS+C implementation to functional-correctness and game-based proof artifacts while reviewers refine the exact theorem and composition boundary.

Existing evidence

Public C code, VST contracts, SSProve/Rocq proofs and automated test, proof and audit commands exist. The repository describes itself as the first WOTS+C construction toward full SHRINCS.

Outstanding questions

Close the EUF-CMA composition gap, model digest ordering, prevent rollback and key reuse, extend coverage to the full SHRINCS scheme, stabilize the C interface and complete independent review.

Last verified

1 Nov 2026

Change since last week

Material review update: a reviewer identified that the current known-message experiment does not yet directly establish standard one-time EUF-CMA security, and requested coverage of digest-before-public-key and state rollback or key reuse.

Bitcoin integration: None. This is a cryptographic implementation and proof artifact, not Bitcoin Script, a BIP, Bitcoin Core code or a deployed spending path.
What the proof covers: A theorem connects the C implementation to a game-based one-time unforgeability result for the current WOTS+C construction.
Current review boundary: The reviewer argues that the known-message experiment needs an explicit reduction or stronger theorem before it can support a standard one-time EUF-CMA claim.
State safety: Rollback and one-time-key reuse remain explicit operational proof obligations.
Deployment status: Research proof-of-concept; not for production use.

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

1 Nov 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 · complete26 OCT–01 NOV 2026Published 02 Nov Previous19–25 OCT 2026Published 26 Oct Earlier12–18 OCT 2026Published 19 Oct