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

This new witness version, designated as version 3, is detailed in the provided BIP text and includes a reference implementation that applies cleanly against a specific commit of the bitcoin/bitcoin repository. The design of this implementation specifies that outputs should utilize a 32-byte SHA-256 hash of the ML-DSA-65 public key, formatted in bech32m with a "bc1r" prefix on the mainnet. The witness stack would entail a large 3309-byte signature and a 1952-byte public key, aligning with the Taproot 0x50 annex convention. Notably, verification processes occur within VerifyWitnessProgram without the need for script execution, thereby circumventing traditional script-based limitations.

In terms of transaction management, this proposal introduces a new script flag and deployment bit specifically for this upgrade, along with five unique script errors relevant to the post-quantum context. This setup allows for deployment via a soft fork, where non-upgraded nodes will treat these new outputs as anyone-can-spend, thus maintaining backward compatibility as per BIP 141. The proposed changes also include considerations for sighash configurations, opting for a tagged hash approach dubbed "PQSighash," which utilizes existing BIP 341 precomputed hashes but differentiates from Taproot sighash through unique identifiers like epoch bytes and spend-type bytes.

Critically, the proposed ML-DSA-65 was chosen over other cryptographic schemes such as SLH-DSA or hybrid ECDSA+PQ due to its relatively compact signature size under 3.5 kB, despite being approximately eight times larger than alternatives. This choice, however, remains open for discussion, particularly in relation to its deployment implications on transaction sizes and fees. For instance, a typical post-quantum spend might cost significantly more in transaction fees compared to current standards, raising concerns about scalability and economic viability.

Furthermore, the dependency on liboqs 0.15.0 for prototyping poses a notable risk as it introduces an external consensus-critical dependency, underscoring the necessity for a more secure integration of ML-DSA-65 into the Bitcoin core before full activation.

This initiative also prompts several important questions needing community feedback, especially concerning the construction of the new sighash, the decision between introducing a new witness version versus extending Tapscript opcode, and the feasibility of integrating ML-DSA directly into the Bitcoin core. Moreover, the proposal seeks input on historical discussions and further insights into post-quantum cryptographic approaches, ensuring a comprehensive evaluation before any formal adoption.