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

Posted by echelonresearch

Apr 16, 2026/08:28 UTC

The recent proposal for adding a post-quantum key-path spending mechanism to Bitcoin introduces a new witness version, specifically version 3, utilizing the FIPS 204 ML-DSA-65 (NIST Level 3) cryptographic standard. This initiative, documented in a draft BIP available here, aims to enhance the blockchain's security against quantum computing threats. The proposed method would not require script execution as it operates within the VerifyWitnessProgram, thus bypassing traditional script interpretation and related size constraints.

The implementation details include using a 32-byte SHA-256 hash of the public key, formatted in the bech32m address with a "bc1r" prefix for mainnet. Transactions are to utilize a new signature hash (sighash) dubbed "PQSighash", incorporating specific configurations such as epoch byte and extended flags to differentiate it from existing Taproot applications while maintaining compatibility with BIP 341 precomputed hashes.

Concerning deployment, this would be introduced as a soft fork under BIP 9 protocols, where non-updated nodes will treat these transactions as anyone-can-spend, preserving network integrity. This strategy aligns with the broader roadmap discussed in BIP 361 concerning migration from legacy cryptographic methods to more secure alternatives amid quantum advancements. However, this proposal serves only as one potential solution among others being considered within the community.

Several technical and strategic considerations accompany this proposal. For instance, the choice of ML-DSA-65 over other cryptographic schemes like SLH-DSA or Falcon was made to keep signature sizes below 3.5 kB, despite possible trade-offs in terms of signature size and computational overhead. The impact on transaction sizes and fees is significant, with estimates suggesting a substantial increase in weight units consumed per transaction, necessitating further discussions about network fee structures and block validation times.

Moreover, the reference implementation currently depends on the liboqs library, version 0.15.0, which might not be ideal for long-term consensus-critical applications. Discussions are encouraged regarding whether to integrate this library directly into the Bitcoin core codebase to mitigate external dependency risks. Additionally, feedback is sought on several fronts including the new sighash construction, the comparison between a new witness version versus a Tapscript opcode, and general community interest in pursuing this quantum-resistant pathway.

The introduction of such advanced cryptographic measures indicates a proactive approach to securing Bitcoin against emerging technological threats, highlighting the ongoing need for innovation and adaptation within the cryptocurrency ecosystem.

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