Hi Zeeshan, all,<br /><br />Thank you, both points are right, and they are now part of a substantially<br />revised draft (v0.2):<br /><br />https://github.com/Zaenus/btc-safe/blob/main/docs/bip/0001-pq-address-format.md<br /><br />&gt; I think this is definitely useful **before** a CRQC exists.<br /><br />Agreed. The Motivation section now spells out why waiting fails. Soft<br />forks take years from proposal to activation, and migration is limited<br />by block space: a 1-in/1-out move from P2WPKH to the new output type is<br />486 WU, so every 10 million UTXOs needs roughly 1,200 completely full<br />blocks. A safe destination has to exist well before the threat does.<br /><br />&gt; I think it'd be useful to highlight that unlike a P2WPKH address, the<br />&gt; address remains quantum-resistant even after its public key and<br />&gt; signatures are revealed.<br /><br />Yes. My comparison with P2WPKH undersold the design. The hash commitment<br />only keeps outputs small (34 bytes instead of ~1,955); it is not what<br />provides security. Unlike P2WPKH, the output stays safe while a spend<br />waits in the mempool, after it has been spent, and under address reuse<br />(still bad for privacy, of course). The draft now says this explicitly.<br /><br />Corrections to my original post<br />-------------------------------<br /><br />Several things in my first message were wrong, and I want to correct them<br />on the list:<br /><br />1. Witness version 2 / bc1z: version 2 is used by BIP-360 (P2MR). The<br />   proposal now uses witness version 3, so addresses start with bc1r<br />   (tb1r on testnet).<br /><br />2. "Similar to how P2WPKH works": misleading, see above.<br /><br />3. "~6.9 million BTC (~$586B)": I replaced this with the figure cited in<br />   BIP-361 (more than 34% of all bitcoin had an exposed public key as of<br />   March 2026) and dropped the dollar value.<br /><br />4. The signature aggregation claim ("~33KB to ~2KB for 10 signatures")<br />   is withdrawn. The prototype was a mock that could be forged, and the<br />   approach was unsound anyway: pairing-based SNARKs such as Groth16 are<br />   themselves broken by a CRQC, and consensus cannot depend on a trusted<br />   setup. Aggregation is now out of scope; a short research note<br />   explains what a sound approach would need.<br /><br />5. The reference implementation produced bech32 rather than bech32m<br />   checksums for the new witness version, so BIP-350 wallets would have<br />   rejected its addresses. That is fixed and tested against the BIP-350<br />   vectors. It also generated mainnet addresses by default; it now<br />   defaults to testnet, since these outputs are anyone-can-spend until a<br />   soft fork activates.<br /><br />What changed in the design<br />--------------------------<br /><br />  key_blob     = key_type || pubkey             (0x01 = ML-DSA-65)<br />  commitment   = TaggedHash("PQKeyCommit", key_blob)<br />  scriptPubKey = OP_3 &lt;32-byte commitment&gt;<br />  witness      = &lt;signature[||hash_type]&gt; &lt;key_blob&gt; [annex]<br />  sighash      = TaggedHash("PQSighash", 0x00 || SigMsg(hash_type, 0))<br />  verify       = ML-DSA.Verify(pk, sighash, sig, ctx="bitcoin:pq:tx")<br /><br />- Key type byte: the key blob is always the last witness element, and<br />  undefined key types succeed (like OP_SUCCESS). ML-DSA-44, SLH-DSA,<br />  FN-DSA or a hybrid type can then be added by later soft forks without<br />  spending another witness version.<br /><br />- The signature message is BIP-341's SigMsg, unchanged, under a new tag.<br />  It commits to all input amounts and scriptPubKeys, which BIP-143 does<br />  not.<br /><br />- FIPS 204 context strings separate transaction signatures from<br />  off-chain message signatures.<br /><br />- The draft now has full spending rules, relay policy, size figures, and<br />  a rationale section comparing this with P2MR (BIP-360), hybrid keys,<br />  ML-DSA-44, SLH-DSA and FN-DSA.<br /><br />- Test vectors (docs/bip/0001-test-vectors.json) cover keys and<br />  derivation, all seven hash types, and 32 valid and invalid spends. The<br />  signatures come from an independent ML-DSA implementation, and the<br />  sighash code also passes the official BIP-341 vectors.<br /><br />Size: an ML-DSA-65 input is 5,433 WU (~1,358 vB), about 736 per block. A<br />1-in/2-out transaction is about 1,455 vB.<br /><br />Status of my original questions<br />-------------------------------<br /><br />1. Address format: revised as above (witness v3, bech32m, tagged-hash<br />   commitment with a key type byte).<br /><br />2. ML-DSA-65 vs. smaller parameters: still open, and I would value<br />   opinions. ML-DSA-44 inputs are 28% smaller (3,904 WU); ML-DSA-65<br />   gives more margin against future lattice cryptanalysis. Should a<br />   hybrid secp256k1 + ML-DSA key type also exist from day one?<br /><br />3. Deployment: no activation mechanism proposed yet. Bitcoin Core<br />   benchmarks of ML-DSA-65 verification come first.<br /><br />4. Migration: the reference tools classify addresses by exposure<br />   (Taproot and spent-from addresses count as exposed) and derive<br />   recoverable destinations from a BIP-39 seed. BIP-361 covers the<br />   policy side.<br /><br />5. Before a CRQC: yes, per Zeeshan's reply and the reasoning above.<br /><br />Detailed technical discussion is also happening on Delving Bitcoin:<br />https://delvingbitcoin.org/t/bip-draft-witness-version-3-ml-dsa-65-post-quantum-key-path-spending/<br /><br />Full list of changes:<br />https://github.com/Zaenus/btc-safe/blob/main/CHANGELOG.md<br /><br />Thanks again for the review.<br /><br />Best regards,<br />Hans<br />https://github.com/Zaenus<br /><br /><div class="gmail_quote"><div dir="auto" class="gmail_attr">Em sexta-feira, 13 de novembro de 2026 às 13:28:40 UTC-3, Zeeshan Ali Khan escreveu:<br/></div><blockquote class="gmail_quote" style="margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi Hans,
<br>
<br>&gt; 5. Whether the community sees value in pursuing this before a CRQC exists
<br>
<br>I can&#39;t speak for others but I think this is definitely useful
<br>**before** a CRQC exists. It&#39;d be too late for the 6.9 million BTC you
<br>mentioned when there is CRQC. :)
<br>
<br>&gt; revealing the full public key only at spend time in the witness — similar to how P2WPKH works today.
<br>
<br>I think it&#39;d be useful to highlight that unlike a P2WPKH address, the
<br>address remains quantum-resistant even after its public key and
<br>signatures are revealed.
<br>
<br>--
<br>Regards,
<br>
<br>Zeeshan Ali Khan
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoindev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href="https://groups.google.com/d/msgid/bitcoindev/23d3f227-fb57-4ad3-8dab-438d2bd6e651n%40googlegroups.com?utm_medium=email&utm_source=footer">https://groups.google.com/d/msgid/bitcoindev/23d3f227-fb57-4ad3-8dab-438d2bd6e651n%40googlegroups.com</a>.<br />