From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 13 Nov 2026 09:26:28 -0800 Received: from mail-oa1-f60.google.com ([209.85.160.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1xRv2h-000RTN-EA for bitcoindev@gnusha.org; Fri, 13 Nov 2026 09:26:28 -0800 Received: by mail-oa1-f60.google.com with SMTP id 586e51a60fabf-46509ab0149sf1251524fac.2 for ; Fri, 13 Nov 2026 09:26:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20260707; t=1794590781; x=1795195581; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:references:in-reply-to:message-id:to:from:date :sender:from:to:cc:subject:date:message-id:reply-to:content-type; bh=Hk+yTMDhO/ROyCBaEP02QtPwvA2mRWv/t+YZ5Tk8I6s=; b=gTmVX+DGy67kr6Vpnc69FQtX6faw+WsMVgDtXRpGEqEhAD4fhAgHsq6tp6MiPeIINd MnhRmd0+2/r2i+aQNfNP7wQ3E9GDzkPnw4eOmpcUpXDYvj3uKHQjBay1aWY8i1gfK1bH ZffwHKIfYpx5fTE9UWPLwNQ1ownqexjQTAXaGvo69uE6LJQrSlYJ9FXaK/WoLTk7aDYm bPQrUgB+w14e8qhAtW+8+stCnnUKGVc4Zo60/5Ylza/6REg5fCRl+UBYi/PWaLk/x8sK t2eUkujWoWWJJ+sjaGNKduiazlGhteQ0i5cmuJCDRkgqlbjt6C33fa1cBjk+SjJYkg6M +0XQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20260707; t=1794590781; x=1795195581; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:references:in-reply-to:message-id:to:from:date :from:to:cc:subject:date:message-id:reply-to:content-type; bh=Hk+yTMDhO/ROyCBaEP02QtPwvA2mRWv/t+YZ5Tk8I6s=; b=UU/NA9Ho/MfK1Yo+nBWwXgBjGDXbaA5K2jNc3EGMEtccpULmyYLjuozwCsGlhzO9rf GBluhJr+CqO8z8lHbqMkz3DFDLpqNo4FKhJQV7mDZtx0kkCCM792r+jD+frIJqAZT6rD ZB5b7HsSGljQ5Pfu6788xEMMJvy1NZK08bLgDWvBWHH/4bWS//bm1GwsWtNJn0Rfgw2H oAZxU70n5GsEODPIZeGhEhffjHj8cEuza0RST3npIX6gyNiRtlc7KhwlBGiikQXBhgDU 3h1ZT+QbZMgaxIjWQs+SCDKM7fc+19xF+xMMdtDz5JyHWmDjDfFhfHth9/Eum85mMM0u 9nMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1794590781; x=1795195581; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:references:in-reply-to:message-id:to:from:date :x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Hk+yTMDhO/ROyCBaEP02QtPwvA2mRWv/t+YZ5Tk8I6s=; b=kZDikkFRmk6bre5N7sB9ypardu7Ql8Z/nPQW8TIJj4dkdJgxCOq5uz63DnrULKXt6a 2ZBC6nhgvj8aBbyRXZtcDQjHOzS6ZRkpLiTEq22XRGel32HFu3yx5CKIWJg0+2EqtrGA 8uyB3rgMnjb1HiDCSQ5IV6SU4y8sOylOIOjT/aKOBJ35rgp1r7qKX+kfU+ONVH+Nl8LN tpSj7ao6U1aDNeNo7jWteqAuPMTQA3pUeVvXnEzPO8R9CMsFOqFZd7yPrNM6xhUClfJ+ oRYZvQhd5ntuKJRN6zNvUDVZd5tIuHUmuMFp7/Z1WBvCr3YWOSA7SLVqrfH6ZHRI6uNE wE5Q== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AL+hErHkT9tD14nNdkIT4Ucyla/+B1yuhXJtT8PzhyfizYwLEZzgKPfI5jcb4oaFkXe9OMOqf8cqShzDI0n2@gnusha.org X-Gm-Message-State: APuU4Z9OEbrEXZ6nthGqikzOZYv71PyjkPWf4yQRWjPbUfMFlwiYFkWZ 6/idaMa+9tT4NEzupdOfJXTPsloAcYhQlsqM9+Ou+2dLVHKFghTaKx3n X-Received: by 2002:a05:6870:b06:b0:46a:ce42:d731 with SMTP id 586e51a60fabf-4afdf49242dmr2989596fac.9.1794590781337; Fri, 13 Nov 2026 09:26:21 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLdfnpTdOPiwQZBz9O6zqQ7jNaIBqHfEwFL5sy7MWwOPrqA==" Received: by 2002:a05:6871:81ca:20b0:479:bbe:a714 with SMTP id 586e51a60fabf-4afdeb0e2cbls995291fac.0.-pod-prod-08-us; Fri, 13 Nov 2026 09:26:15 -0800 (PST) X-Received: by 2002:a05:6808:c234:b0:4d6:9153:295e with SMTP id 5614622812f47-56e6510fdb8mr2586574b6e.47.1794590775438; Fri, 13 Nov 2026 09:26:15 -0800 (PST) Received: by 2002:a05:690c:8d0f:b0:8b0:7cd2:a7ee with SMTP id 00721157ae682-8b4b0e655f4ms7b3; Fri, 13 Nov 2026 09:25:19 -0800 (PST) X-Received: by 2002:a05:690c:e3ed:b0:8b0:ca83:c5a1 with SMTP id 00721157ae682-8b4a9ff1dc4mr24691007b3.0.1794590718940; Fri, 13 Nov 2026 09:25:18 -0800 (PST) Date: Fri, 13 Nov 2026 09:25:18 -0800 (PST) From: Hans Stringuer To: Bitcoin Development Mailing List Message-Id: <23d3f227-fb57-4ad3-8dab-438d2bd6e651n@googlegroups.com> In-Reply-To: References: <9463348c-b2ec-4c6f-b9ec-2e9e2fc7d105n@googlegroups.com> Subject: Re: [bitcoindev] BIP Draft Post-Quantum Address Format (bc1z) using ML-DSA-65 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_5217_629349360.1794590718637" X-Original-Sender: hans.stringuer@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_5217_629349360.1794590718637 Content-Type: multipart/alternative; boundary="----=_Part_5218_857039277.1794590718637" ------=_Part_5218_857039277.1794590718637 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Zeeshan, all, Thank you, both points are right, and they are now part of a substantially revised draft (v0.2): https://github.com/Zaenus/btc-safe/blob/main/docs/bip/0001-pq-address-forma= t.md > I think this is definitely useful **before** a CRQC exists. Agreed. The Motivation section now spells out why waiting fails. Soft forks take years from proposal to activation, and migration is limited by block space: a 1-in/1-out move from P2WPKH to the new output type is 486 WU, so every 10 million UTXOs needs roughly 1,200 completely full blocks. A safe destination has to exist well before the threat does. > I think it'd be useful to highlight that unlike a P2WPKH address, the > address remains quantum-resistant even after its public key and > signatures are revealed. Yes. My comparison with P2WPKH undersold the design. The hash commitment only keeps outputs small (34 bytes instead of ~1,955); it is not what provides security. Unlike P2WPKH, the output stays safe while a spend waits in the mempool, after it has been spent, and under address reuse (still bad for privacy, of course). The draft now says this explicitly. Corrections to my original post ------------------------------- Several things in my first message were wrong, and I want to correct them on the list: 1. Witness version 2 / bc1z: version 2 is used by BIP-360 (P2MR). The proposal now uses witness version 3, so addresses start with bc1r (tb1r on testnet). 2. "Similar to how P2WPKH works": misleading, see above. 3. "~6.9 million BTC (~$586B)": I replaced this with the figure cited in BIP-361 (more than 34% of all bitcoin had an exposed public key as of March 2026) and dropped the dollar value. 4. The signature aggregation claim ("~33KB to ~2KB for 10 signatures") is withdrawn. The prototype was a mock that could be forged, and the approach was unsound anyway: pairing-based SNARKs such as Groth16 are themselves broken by a CRQC, and consensus cannot depend on a trusted setup. Aggregation is now out of scope; a short research note explains what a sound approach would need. 5. The reference implementation produced bech32 rather than bech32m checksums for the new witness version, so BIP-350 wallets would have rejected its addresses. That is fixed and tested against the BIP-350 vectors. It also generated mainnet addresses by default; it now defaults to testnet, since these outputs are anyone-can-spend until a soft fork activates. What changed in the design -------------------------- key_blob =3D key_type || pubkey (0x01 =3D ML-DSA-65) commitment =3D TaggedHash("PQKeyCommit", key_blob) scriptPubKey =3D OP_3 <32-byte commitment> witness =3D [annex] sighash =3D TaggedHash("PQSighash", 0x00 || SigMsg(hash_type, 0)) verify =3D ML-DSA.Verify(pk, sighash, sig, ctx=3D"bitcoin:pq:tx") - Key type byte: the key blob is always the last witness element, and undefined key types succeed (like OP_SUCCESS). ML-DSA-44, SLH-DSA, FN-DSA or a hybrid type can then be added by later soft forks without spending another witness version. - The signature message is BIP-341's SigMsg, unchanged, under a new tag. It commits to all input amounts and scriptPubKeys, which BIP-143 does not. - FIPS 204 context strings separate transaction signatures from off-chain message signatures. - The draft now has full spending rules, relay policy, size figures, and a rationale section comparing this with P2MR (BIP-360), hybrid keys, ML-DSA-44, SLH-DSA and FN-DSA. - Test vectors (docs/bip/0001-test-vectors.json) cover keys and derivation, all seven hash types, and 32 valid and invalid spends. The signatures come from an independent ML-DSA implementation, and the sighash code also passes the official BIP-341 vectors. Size: an ML-DSA-65 input is 5,433 WU (~1,358 vB), about 736 per block. A 1-in/2-out transaction is about 1,455 vB. Status of my original questions ------------------------------- 1. Address format: revised as above (witness v3, bech32m, tagged-hash commitment with a key type byte). 2. ML-DSA-65 vs. smaller parameters: still open, and I would value opinions. ML-DSA-44 inputs are 28% smaller (3,904 WU); ML-DSA-65 gives more margin against future lattice cryptanalysis. Should a hybrid secp256k1 + ML-DSA key type also exist from day one? 3. Deployment: no activation mechanism proposed yet. Bitcoin Core benchmarks of ML-DSA-65 verification come first. 4. Migration: the reference tools classify addresses by exposure (Taproot and spent-from addresses count as exposed) and derive recoverable destinations from a BIP-39 seed. BIP-361 covers the policy side. 5. Before a CRQC: yes, per Zeeshan's reply and the reasoning above. Detailed technical discussion is also happening on Delving Bitcoin: https://delvingbitcoin.org/t/bip-draft-witness-version-3-ml-dsa-65-post-qua= ntum-key-path-spending/ Full list of changes: https://github.com/Zaenus/btc-safe/blob/main/CHANGELOG.md Thanks again for the review. Best regards, Hans https://github.com/Zaenus Em sexta-feira, 13 de novembro de 2026 =C3=A0s 13:28:40 UTC-3, Zeeshan Ali = Khan=20 escreveu: > Hi Hans, > > > 5. Whether the community sees value in pursuing this before a CRQC exis= ts > > I can't speak for others but I think this is definitely useful > **before** a CRQC exists. It'd be too late for the 6.9 million BTC you > mentioned when there is CRQC. :) > > > revealing the full public key only at spend time in the witness =E2=80= =94=20 > similar to how P2WPKH works today. > > I think it'd be useful to highlight that unlike a P2WPKH address, the > address remains quantum-resistant even after its public key and > signatures are revealed. > > -- > Regards, > > Zeeshan Ali Khan > --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 23d3f227-fb57-4ad3-8dab-438d2bd6e651n%40googlegroups.com. ------=_Part_5218_857039277.1794590718637 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Zeeshan, all,

Thank you, both points are right, and they are = now part of a substantially
revised draft (v0.2):

https://g= ithub.com/Zaenus/btc-safe/blob/main/docs/bip/0001-pq-address-format.md

> I think this is definitely useful **before** a CRQC exists.

Agreed. The Motivation section now spells out why waiting fails. So= ft
forks take years from proposal to activation, and migration is limi= ted
by block space: a 1-in/1-out move from P2WPKH to the new output ty= pe is
486 WU, so every 10 million UTXOs needs roughly 1,200 completely= full
blocks. A safe destination has to exist well before the threat d= oes.

> I think it'd be useful to highlight that unlike a P2WP= KH address, the
> address remains quantum-resistant even after its = public key and
> signatures are revealed.

Yes. My compar= ison with P2WPKH undersold the design. The hash commitment
only keeps = outputs small (34 bytes instead of ~1,955); it is not what
provides se= curity. Unlike P2WPKH, the output stays safe while a spend
waits in th= e mempool, after it has been spent, and under address reuse
(still bad= for privacy, of course). The draft now says this explicitly.

Co= rrections to my original post
-------------------------------
Several things in my first message were wrong, and I want to correct the= m
on the list:

1. Witness version 2 / bc1z: version 2 is us= ed by BIP-360 (P2MR). The
=C2=A0 =C2=A0proposal now uses witness versi= on 3, so addresses start with bc1r
=C2=A0 =C2=A0(tb1r on testnet).

2. "Similar to how P2WPKH works": misleading, see above.

3. "~6.9 million BTC (~$586B)": I replaced this with the figure cited in=C2=A0 =C2=A0BIP-361 (more than 34% of all bitcoin had an exposed publi= c key as of
=C2=A0 =C2=A0March 2026) and dropped the dollar value.

4. The signature aggregation claim ("~33KB to ~2KB for 10 signature= s")
=C2=A0 =C2=A0is withdrawn. The prototype was a mock that could be = forged, and the
=C2=A0 =C2=A0approach was unsound anyway: pairing-base= d SNARKs such as Groth16 are
=C2=A0 =C2=A0themselves broken by a CRQC,= and consensus cannot depend on a trusted
=C2=A0 =C2=A0setup. Aggregat= ion is now out of scope; a short research note
=C2=A0 =C2=A0explains w= hat a sound approach would need.

5. The reference implementation= produced bech32 rather than bech32m
=C2=A0 =C2=A0checksums for the ne= w witness version, so BIP-350 wallets would have
=C2=A0 =C2=A0rejected= its addresses. That is fixed and tested against the BIP-350
=C2=A0 = =C2=A0vectors. It also generated mainnet addresses by default; it now
= =C2=A0 =C2=A0defaults to testnet, since these outputs are anyone-can-spend = until a
=C2=A0 =C2=A0soft fork activates.

What changed in t= he design
--------------------------

=C2=A0 key_blob =C2=A0= =C2=A0 =3D key_type || pubkey =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (0= x01 =3D ML-DSA-65)
=C2=A0 commitment =C2=A0 =3D TaggedHash("PQKeyCommi= t", key_blob)
=C2=A0 scriptPubKey =3D OP_3 <32-byte commitment><= br />=C2=A0 witness =C2=A0 =C2=A0 =C2=A0=3D <signature[||hash_type]> = <key_blob> [annex]
=C2=A0 sighash =C2=A0 =C2=A0 =C2=A0=3D Tagged= Hash("PQSighash", 0x00 || SigMsg(hash_type, 0))
=C2=A0 verify =C2=A0 = =C2=A0 =C2=A0 =3D ML-DSA.Verify(pk, sighash, sig, ctx=3D"bitcoin:pq:tx")
- Key type byte: the key blob is always the last witness element, = and
=C2=A0 undefined key types succeed (like OP_SUCCESS). ML-DSA-44, S= LH-DSA,
=C2=A0 FN-DSA or a hybrid type can then be added by later soft= forks without
=C2=A0 spending another witness version.

- T= he signature message is BIP-341's SigMsg, unchanged, under a new tag.
= =C2=A0 It commits to all input amounts and scriptPubKeys, which BIP-143 doe= s
=C2=A0 not.

- FIPS 204 context strings separate transacti= on signatures from
=C2=A0 off-chain message signatures.

- T= he draft now has full spending rules, relay policy, size figures, and
= =C2=A0 a rationale section comparing this with P2MR (BIP-360), hybrid keys,=
=C2=A0 ML-DSA-44, SLH-DSA and FN-DSA.

- Test vectors (docs= /bip/0001-test-vectors.json) cover keys and
=C2=A0 derivation, all sev= en hash types, and 32 valid and invalid spends. The
=C2=A0 signatures = come from an independent ML-DSA implementation, and the
=C2=A0 sighash= code also passes the official BIP-341 vectors.

Size: an ML-DSA-= 65 input is 5,433 WU (~1,358 vB), about 736 per block. A
1-in/2-out tr= ansaction is about 1,455 vB.

Status of my original questions
-------------------------------

1. Address format: revised as = above (witness v3, bech32m, tagged-hash
=C2=A0 =C2=A0commitment with a= key type byte).

2. ML-DSA-65 vs. smaller parameters: still open= , and I would value
=C2=A0 =C2=A0opinions. ML-DSA-44 inputs are 28% sm= aller (3,904 WU); ML-DSA-65
=C2=A0 =C2=A0gives more margin against fut= ure lattice cryptanalysis. Should a
=C2=A0 =C2=A0hybrid secp256k1 + ML= -DSA key type also exist from day one?

3. Deployment: no activat= ion mechanism proposed yet. Bitcoin Core
=C2=A0 =C2=A0benchmarks of ML= -DSA-65 verification come first.

4. Migration: the reference too= ls classify addresses by exposure
=C2=A0 =C2=A0(Taproot and spent-from= addresses count as exposed) and derive
=C2=A0 =C2=A0recoverable desti= nations from a BIP-39 seed. BIP-361 covers the
=C2=A0 =C2=A0policy sid= e.

5. Before a CRQC: yes, per Zeeshan's reply and the reasoning = above.

Detailed technical discussion is also happening on Delvin= g Bitcoin:
https://delvingbitcoin.org/t/bip-draft-witness-version-3-ml= -dsa-65-post-quantum-key-path-spending/

Full list of changes:https://github.com/Zaenus/btc-safe/blob/main/CHANGELOG.md

Tha= nks again for the review.

Best regards,
Hans
https://g= ithub.com/Zaenus

Em sexta-feira, 13 de novembro de 2026 =C3=A0s 13:28:40 = UTC-3, Zeeshan Ali Khan escreveu:
Hi Hans,

> 5. Whether the community sees value in pursuing this before a CRQC= exists

I can't speak for others but I think this is definitely useful
**before** a CRQC exists. It'd be too late for the 6.9 million BTC = you
mentioned when there is CRQC. :)

> revealing the full public key only at spend time in the witness = =E2=80=94 similar to how P2WPKH works today.

I think it'd be useful to highlight that unlike a P2WPKH address, t= he
address remains quantum-resistant even after its public key and
signatures are revealed.

--
Regards,

Zeeshan Ali Khan

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/23d3f227-fb57-4ad3-8dab-438d2bd6e651n%40googlegroups.com.
------=_Part_5218_857039277.1794590718637-- ------=_Part_5217_629349360.1794590718637--