Bitcoin Quantum Preparedness

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 gives reviewers a shared comparison surface for output semantics, deployment choices and cost accounting.

Previous state

Design discussion was distributed across several threads.

Current state

Alternatives are documented together; no design has consensus.

Primary sourceDelving Bitcoin

02 / Protocol & BIP tracker

Protocol work

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

Latest activity

Regtest measurements were added to the output-type discussion; BIP version 0.12.1 remains Draft.

Dependencies

BIPs 340, 341 and 342; future post-quantum opcode or leaf design.

Open technical questions

Witness-version assignment, leaf policy, cost model and post-quantum opcode selection.

Governance questions

Competes for witness version 2 with BIP 460; no activation process agreed.

Contributors

Hunter Beast, Ethan Heilman, Isabel Foxen Duke and reviewers.

Last verified

15 Aug 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 and benchmarking

Current state

Current status

Research and benchmarking

Current documented activity

Proposed script opcode or leaf path, with separate witness treatment under discussion.

Existing evidence

Technical reports and benchmark discussions; no Bitcoin consensus deployment.

Outstanding questions

No separate outstanding-question statement in the source record.

Last verified

15 Aug 2026

Change since last week

New witness-cost and aggregation discussions were indexed this reporting cycle.

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: Requires explicit authorization-data accounting; witness styles may permit a distinct cost formula.
Multisignature & hardware wallets: Composition and device verification flows remain design questions; no wallet deployment located.
Key generation & recovery: Stateless use avoids a signing-state counter, but seed backup and derivation standards remain open.
Implementation evidence: Technical reports and benchmark discussions; no Bitcoin consensus deployment.

Open primary source

Hash-based · stateful · Blockstream ResearchSHRINCS / OP_CHECKSHRINCSOpcode proposal with implementations and sidechain evidence

Current state

Current status

Opcode proposal with implementations and sidechain evidence

Current documented activity

Blockstream Research is advancing a draft Bitcoin opcode proposal and lists a SHRINCS BIP draft among its Q3 priorities.

Existing evidence

Post-quantum-signed Liquid transactions, a C++ implementation, a Simplicity verifier and a public specification draft are documented.

Outstanding questions

State management, Bitcoin consensus integration, wallet recovery, review and production Bitcoin deployment remain unresolved.

Last verified

15 Aug 2026

Change since last week

No material change located in the current reporting week.

Bitcoin integration: OP_CHECKSHRINCS is proposed as a dedicated Bitcoin opcode; related work is already deployed experimentally on Liquid.
Signature & proof characteristics: Compact stateful hash-based signatures using Bitcoin’s existing SHA-256 assumption.
Transactions, blockspace & fees: The proposal is designed around transaction throughput and authorization-data size.
Multisignature & hardware wallets: Distributed state coordination and safe backup behavior remain open engineering questions.
Key generation & recovery: State reuse must be prevented; static-backup recovery requires scheme-specific handling.

Open primary source

Lattice assumptions · generally statelessLattice-based signature candidatesBitcoin discussion · constrained-device implementation available

Current state

Current status

Bitcoin discussion · constrained-device implementation available

Current documented activity

Bitcoin developers continue to discuss lattice-based signatures while Ledger has implemented ML-DSA and ML-KEM APIs in its device SDK.

Existing evidence

Ledger reports bit-for-bit agreement with NIST test vectors using low-memory implementations on its hardware platform.

Outstanding questions

A Bitcoin opcode, transaction construction, multisignature semantics, wallet derivation and physical side-channel protections remain open.

Last verified

15 Aug 2026

Change since last week

No material Bitcoin-integration change located this week.

Bitcoin integration: Potential dedicated signature opcode, leaf version, or future output construction; Ledger SDK support is not Bitcoin transaction support.
Signature & proof characteristics: Different key and signature shapes than Bitcoin’s current signatures; implementation behavior must be specified.
Transactions, blockspace & fees: Larger authorization data changes transaction assembly, relay and fee estimation.
Multisignature & hardware wallets: Aggregation, deterministic signing, constrained-device memory and reviewable prompts remain open.
Key generation & recovery: Wallet derivation and seed-to-key standards would require ecosystem agreement.

Open primary source

Since last week

Protocol work

Trackers & evidence

Engineering

Snapshots, preserved