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 demonstrates that several Lightning surfaces can be explored through implementation upgrades independently of a Bitcoin consensus change, while clearly separating them from the on-chain funding, commitment and penalty paths that remain unchanged.

Previous state

The Lightning register recorded design discussion but no executable end-to-end post-quantum implementation for off-chain surfaces.

Current state

PQLN is a research fork with a sample node, interoperability scenarios and measured evaluation. It is not an adopted BOLT, an upstream LDK release, a production deployment or a solution for Lightning’s Bitcoin-anchored transaction keys.

Primary sourcePQLN discussion, paper and code

02 / Protocol & BIP tracker

Protocol work

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

Latest activity

The 4 September typed-reference and regression-test merge remains the latest substantiated implementation milestone in this register.

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

27 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.

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

27 Sep 2026

Change since last week

New research: PRAWNS uses context-aware threshold pseudorandom functions so a quorum can assemble an ordinary Winternitz-style hash-based signature without exposing threshold metadata to the verifier.

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

27 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 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

27 Sep 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

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

27 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 · complete21–27 SEP 2026Updated 29 Sep Previous14–20 SEP 2026Published 21 Sep Earlier07–13 SEP 2026Published 14 Sep