[BIP Draft] Witness Version 3: ML-DSA-65 Post-Quantum Key-Path Spending

Apr 16 - Jun 1, 2026

  • The recent proposal for integrating a post-quantum cryptographic method into the Bitcoin protocol by introducing a new witness version highlights a proactive step toward enhancing security against quantum threats.

This approach utilizes the FIPS 204 ML-DSA-65 standard, aiming to secure transactions without the need for script execution by directly verifying within the VerifyWitnessProgram. The details outlined include a new signature hash titled "PQSighash," designed to incorporate features like epoch byte and extended flags, ensuring compatibility with existing BIP 341 hashes while marking a significant shift from current Taproot applications. A soft fork following BIP 9 protocols would deploy this, allowing transactions to be treated as anyone-can-spend by nodes not updated, thus maintaining network integrity.

The proposed mechanism also includes using a 32-byte SHA-256 hash of the public key, formatted in a new bech32m address format with a "bc1r" prefix for mainnet applications. The initiative is documented comprehensively in a draft available here, which provides further technical specifications and the broader context in BIP 361 concerning the transition from legacy cryptographic mechanisms to those capable of withstanding quantum-level threats. However, this is just one potential solution amidst various others being considered within the cryptocurrency community.

Regarding the design choices and implementation specifics, there are substantial queries and concerns. For instance, the selection of ML-DSA-65 aims to provide a 192-bit security level, despite the availability of smaller parameters such as ML-DSA-44, which aligns with the classical security level of secp256k1 but at a reduced size. This decision lacks clear justification given that the larger bit security leads to trade-offs in signature size and computational overhead. Additionally, the adoption of an output type that strictly commits to an ML-DSA key, similar in nature to P2WPKH, restricts cryptographic agility. This limitation could pose risks, especially if ML-DSA becomes vulnerable, suggesting the potential future need for a rescue protocol soft fork.

Furthermore, implementing ML-DSA without witness discounts could significantly decrease transactions per second (TPS), raising scalability issues for the Bitcoin network. Alternative cryptographic schemes, such as SLH-DSA or hash-based signatures like XMSS, offer potentially more efficient solutions in terms of key and signature sizes and do not introduce new cryptographic assumptions. These alternatives could provide similar or improved security and efficiency without the limitations posed by ML-DSA. Such considerations necessitate a thorough evaluation and justification for the chosen cryptographic strategies to ensure they align with the network's performance and security requirements.

Link to Raw Post
Bitcoin Logo

TLDR

Join Our Newsletter

We’ll email you summaries of the latest discussions from high signal bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.

Explore all Products

ChatBTC imageBitcoin searchBitcoin TranscriptsSaving SatoshiDecoding BitcoinWarnet
Built with 🧡 by the Bitcoin Dev Project
View our public visitor count

We'd love to hear your feedback on this project.

Give Feedback