From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 09 Apr 2026 13:34:29 -0700 Received: from mail-ot1-f60.google.com ([209.85.210.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 1wAw56-0003Em-J4 for bitcoindev@gnusha.org; Thu, 09 Apr 2026 13:34:29 -0700 Received: by mail-ot1-f60.google.com with SMTP id 46e09a7af769-7d7f23bd25bsf4166302a34.0 for ; Thu, 09 Apr 2026 13:34:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1775766862; x=1776371662; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=VLcFfnvktpeVCbhlmY0N/6XAaqNJr4kChibsyKURrUc=; b=F4ztRBzYQdVkjlm2wwY5cNSoWI7/Um0Tykq/QFHyI21y5FqqMjdBdkAOh8tmB5v2bG hJ9Qx8GdAJ72Ox7k1FX1jM26O9cBP4k8CVpLXr/YppnkX7SqlqNSKSOlDZzP63x8bA6i EVLo7ztURu5L1vqwteptEhhN5sceB7+sFqrR8yW76PP+ujP9QoqXkJO0ShzpZ3Dig3zc DTxD05jhh/XiclTdb62MtaqX4jzRwb8ShBs4UHngswRCkELgMr61xeXcPricv+Bn3Fe/ fC8fFncezscTjCP4QWD9OSp1AddMqxqNbM5jMB3K/pzV55n+3ETlN4FCUzxIv9ytMZ0n FYfw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775766862; x=1776371662; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=VLcFfnvktpeVCbhlmY0N/6XAaqNJr4kChibsyKURrUc=; b=VxGmogVmqR3x0VSVqp5cldwwyT++V9WJqo3OD093rNjiYfy4gv15KqE+/krnbhiXfo PEXgGdr0OucRwh205Olu/vwbRH5rLPbbZk3MBeBaQcT3u/V2gFLsJU0yEr+osVlIRgW0 SMy2fobCx0UFXTOaU3k37AVgfU8YVmYJ0YFZL5O0zQ1k6mjioDF1h3g313OYHpR1NeOf fWarLya7M3J9nWMk532DbZb+a/+BFR1i2Y6fpYdE5AFkxpmQEi1X/gdA+L2U8MP4ms7x cqpGv42y0ntWIFNzRN0az/0B7X2gdv5GKuNMNSyZ1LGzU46iQez5mb4e+YwqMLr6jZmm lODw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775766862; x=1776371662; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender: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; bh=VLcFfnvktpeVCbhlmY0N/6XAaqNJr4kChibsyKURrUc=; b=Xwgl9d8gLSvONW1atOMIUa7Qr3W39dw94fzcuYw0Nm0uC4gqSmyc+y2h/K80/IN7gu nknFsCuvp0v1SMcDsMq/o7eT4TM3jm48Kz7oxf4UNYX5JpT9mdSYoYjBnAwjiE7uxg+M Aobss2m/Cq93TcAiyWhJQ0o7g7xDN+m0ioeOFhsOhyIWbxJ3UrmjTqpR9ZZL7kI50UIQ +u1NJzTKIHiGxZT/i5aIz4+pBYaFPu9/RXTYOJ+krtBbAGYc2t4FPQ246E3rpwoG4mqN uxG+puHuWl+t2/PP4T5cknQdHW5C1mOuAwfTVJh8SPm3WHnqteg7L+4ALpC45pDW9934 QclA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCXOlxf3MnverZk2dVmD2xssVLkFwVlqLevbIF8wfw2GMRtPcV2FmrWb1fZJ/ZFF41YwcUdAjwfORb5+@gnusha.org X-Gm-Message-State: AOJu0Yzy8o+ug0V0LJcK2Ti6IqlUO8fnPoqilqP/RcvZEq2QQKslrU8Z 2vclcM7/n3xCRyFK4wmcMFOCH0wyhg/edD03vRL09ajpqSNsHu4QXq26 X-Received: by 2002:a05:6820:178c:b0:688:6d55:189 with SMTP id 006d021491bc7-68bf7fc8aaamr182636eaf.18.1775766862369; Thu, 09 Apr 2026 13:34:22 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiJa07V4UfIJJkKuiEaCCYxnMTghbCJ03894wo+Uds187g==" Received: by 2002:a05:6820:1aa8:b0:681:a657:a767 with SMTP id 006d021491bc7-68bc0f5baa6ls149210eaf.1.-pod-prod-05-us; Thu, 09 Apr 2026 13:34:17 -0700 (PDT) X-Received: by 2002:a05:6808:6610:b0:46a:5201:aa36 with SMTP id 5614622812f47-4789f703b55mr397456b6e.42.1775766857347; Thu, 09 Apr 2026 13:34:17 -0700 (PDT) Received: by 2002:a05:690c:62:b0:79a:8019:36f5 with SMTP id 00721157ae682-7ae247e6da2ms7b3; Thu, 9 Apr 2026 13:31:27 -0700 (PDT) X-Received: by 2002:a05:690c:90:b0:7af:6904:3f47 with SMTP id 00721157ae682-7af71476e91mr5031687b3.29.1775766686462; Thu, 09 Apr 2026 13:31:26 -0700 (PDT) Date: Thu, 9 Apr 2026 13:31:26 -0700 (PDT) From: Dplusplus To: Bitcoin Development Mailing List Message-Id: In-Reply-To: <0vqF88LoOnY4GiUB4vf-MdeZpTAtR70tokS3cLwt2DX0e6_fD1X_wyhPwWEdIdm6R88AULObIU08CWsb5QfeoaM5c4yXPqN5wHyCrqMCtfQ=@protonmail.com> References: <0vqF88LoOnY4GiUB4vf-MdeZpTAtR70tokS3cLwt2DX0e6_fD1X_wyhPwWEdIdm6R88AULObIU08CWsb5QfeoaM5c4yXPqN5wHyCrqMCtfQ=@protonmail.com> Subject: [bitcoindev] Re: In defense of a PQ output type MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_9348_756496.1775766686002" X-Original-Sender: dplusplus@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_9348_756496.1775766686002 Content-Type: multipart/alternative; boundary="----=_Part_9349_776609702.1775766686002" ------=_Part_9349_776609702.1775766686002 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Antoine, Yes, +1 on decoupling the PQ signature discussion from the "freeze"=20 discussion. As one example of what this could look like, P2Q ( https://github.com/casey/bips/blob/280fb529b27949b42721bfbf5f255e67b9a1103b= /bip-p2q.md)=20 formalizes that decoupling. P2Q is a new SegWit version (v3) with spending= =20 rules identical to Taproot today, but with an explicit roadmap: a future=20 soft fork could disable key-path spending for v3 outputs only, without=20 touching existing P2TR UTXOs. Users who send to a P2Q address are deliberately opting in to that future= =20 possibility. The cryptographic decision and the social decision about=20 unmigrated coins become cleanly separable. It also preserves Schnorr's=20 benefits (FROST, MuSig2, Taproot channels, etc.) for everyone who wants to= =20 continue using them in the meantime, while P2MR does not. The part that feels strange to me is the assumption I keep seeing that=20 SegWit v1 key-path spending will "simply" be disabled in a future soft=20 fork. That bakes confiscation into the roadmap without ever asking users to= =20 opt in. Whether "freeze" ultimately wins is a decision for the market to=20 make on its own timeline. D++ On Thursday, April 9, 2026 at 12:06:19=E2=80=AFPM UTC-7 Antoine Poinsot wro= te: > Many of us appear to be in favour of introducing post-quantum signatures = to > Bitcoin via a new Tapscript operation, conditioning the CRQC resistance o= n=20 > a > future invalidation of Taproot key spends. I would like to offer an=20 > argument in > favour of introducing such post-quantum signatures as a new output type= =20 > instead, > that does not depend on invalidating a spending path on existing outputs. > > First of all, it's important to clarify what we are trying to achieve. We= =20 > need > to accept that, by virtue of being faced with an uncertain existential=20 > threat to > the network, there are scenarios, however unlikely, in which the network= =20 > does > not survive. Not all plausible futures are worth optimizing for. For=20 > instance, > one in which PoW ends up broken only a few years after EC crypto, or one= =20 > where > the entire Bitcoin userbase *must* migrate within a handful of years. > > I think there are two futures worth optimizing for primarily: > - a CRQC never materializes and users can continue benefiting from the > properties of a Bitcoin network relying on classical cryptographic > assumptions; > - a CRQC materializes on a long enough timeframe that PQ signature scheme= s=20 > that > maintain today's properties can be designed, vetted and adopted, and the= =20 > vast > majority of the userbase migrated. > > And because hope is not a strategy, it's important to also have a "break= =20 > glass" > emergency plan in case a CRQC emerges on a shorter (yet still reasonable) > timeframe. I think the current proposals for hash-based PQ schemes fit th= is > category. If they became the only safe option available, it would=20 > certainly make > Bitcoin a lot less attractive. But having them around is good risk=20 > mitigation > *regardless* of whether a CRQC emerges. > > It's often argued that a freeze will be necessary anyways, therefore we= =20 > might as > well disable the Taproot keyspend path simultaneously and simply introduc= e=20 > the > PQ scheme today in Tapscript. I personally reject the premise, but more > importantly i think we should separate the concerns of 1) making a PQ=20 > scheme > available and 2) freezing vulnerable coins. Yet introducing a PQ scheme= =20 > inside > vulnerable Taproot outputs locks us onto the path of eventually freezing > vulnerable coins, as it will inevitably turn users of the PQ scheme into > supporters of a freeze. > > This approach would tie the availability of a PQ scheme to reaching=20 > consensus on > a future freeze. Frankly, i do not believe the latter is achievable, let= =20 > alone > at this stage with so little evidence that a CRQC will materialize anytim= e=20 > soon. > By contrast, there is a much stronger case for introducing a PQ scheme in= =20 > the > near term purely as a risk mitigation measure. Coupling the two decisions= =20 > would > necessarily delay the deployment of a PQ scheme, unnecessarily exacerbati= ng > risks whether or not CRQCs become a reality. > > Another drawback of the PQ output type approach is that it would make tho= se > outputs distinguishable from Taproot ones, which is suboptimal in the=20 > event that > a CRQC never materializes. But i would argue that even in this case, the= =20 > cost is > minimal. The users most likely to adopt PQ outputs today (those securing= =20 > large > amounts of BTC with a small set of keys) already have vastly different=20 > usage > patterns from Taproot users: they often reuse addresses and use legacy=20 > output > types (and show little interest in upgrading). > > Best, > Antoine Poinsot > --=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/= dbaf0dcf-3a47-4790-b45a-639a22de45b9n%40googlegroups.com. ------=_Part_9349_776609702.1775766686002 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Antoine,

Yes, +1 on decoupling the PQ signature di= scussion from the "freeze" discussion.

As one example of what this could look like, P2Q (https://github.com/cas= ey/bips/blob/280fb529b27949b42721bfbf5f255e67b9a1103b/bip-p2q.md= ) formalizes that decoupling. P2Q is = a new SegWit version (v3) with spending rules identical to Taproot today, b= ut with an explicit roadmap: a future soft fork could disable key-path spen= ding for v3 outputs only, without touching existing P2TR UTXOs.

<= p dir=3D"ltr" style=3D"line-height: 1.38; margin-top: 12pt; margin-bottom: = 12pt;">Users who send to a P2Q addres= s are deliberately opting in to that future possibility. The cryptographic = decision and the social decision about unmigrated coins become cleanly sepa= rable. It also preserves Schnorr's benefits (FROST, MuSig2, Taproot channel= s, etc.) for everyone who wants to continue using them in the meantime, whi= le P2MR does not.

T= he part that feels strange to me is the assumption I keep seeing that SegWi= t v1 key-path spending will "simply" be disabled in a future soft fork. Tha= t bakes confiscation into the roadmap without ever asking users to opt in. = Whether "freeze" ultimately wins is a decision for the market to make on it= s own timeline.

D++=

On Thursday, April 9, 2026 at 12:06:19=E2=80=AFPM UTC-7 Antoine Poinsot w= rote:
Many of= us appear to be in favour of introducing post-quantum signatures to
Bitcoin via a new Tapscript operation, conditioning the CRQC resistance= on a
future invalidation of Taproot key spends. I would like to offer an arg= ument in
favour of introducing such post-quantum signatures as a new output type= instead,
that does not depend on invalidating a spending path on existing output= s.

First of all, it's important to clarify what we are trying to achie= ve. We need
to accept that, by virtue of being faced with an uncertain existential = threat to
the network, there are scenarios, however unlikely, in which the networ= k does
not survive. Not all plausible futures are worth optimizing for. For in= stance,
one in which PoW ends up broken only a few years after EC crypto, or on= e where
the entire Bitcoin userbase *must* migrate within a handful of years.

I think there are two futures worth optimizing for primarily:
- a CRQC never materializes and users can continue benefiting from the
properties of a Bitcoin network relying on classical cryptographic
assumptions;
- a CRQC materializes on a long enough timeframe that PQ signature sche= mes that
maintain today's properties can be designed, vetted and adopted, = and the vast
majority of the userbase migrated.

And because hope is not a strategy, it's important to also have a &= quot;break glass"
emergency plan in case a CRQC emerges on a shorter (yet still reasonabl= e)
timeframe. I think the current proposals for hash-based PQ schemes fit = this
category. If they became the only safe option available, it would certa= inly make
Bitcoin a lot less attractive. But having them around is good risk miti= gation
*regardless* of whether a CRQC emerges.

It's often argued that a freeze will be necessary anyways, therefor= e we might as
well disable the Taproot keyspend path simultaneously and simply introd= uce the
PQ scheme today in Tapscript. I personally reject the premise, but more
importantly i think we should separate the concerns of 1) making a PQ s= cheme
available and 2) freezing vulnerable coins. Yet introducing a PQ scheme= inside
vulnerable Taproot outputs locks us onto the path of eventually freezin= g
vulnerable coins, as it will inevitably turn users of the PQ scheme int= o
supporters of a freeze.

This approach would tie the availability of a PQ scheme to reaching con= sensus on
a future freeze. Frankly, i do not believe the latter is achievable, le= t alone
at this stage with so little evidence that a CRQC will materialize anyt= ime soon.
By contrast, there is a much stronger case for introducing a PQ scheme = in the
near term purely as a risk mitigation measure. Coupling the two decisi= ons would
necessarily delay the deployment of a PQ scheme, unnecessarily exacerba= ting
risks whether or not CRQCs become a reality.

Another drawback of the PQ output type approach is that it would make t= hose
outputs distinguishable from Taproot ones, which is suboptimal in the e= vent that
a CRQC never materializes. But i would argue that even in this case, th= e cost is
minimal. The users most likely to adopt PQ outputs today (those securin= g large
amounts of BTC with a small set of keys) already have vastly different = usage
patterns from Taproot users: they often reuse addresses and use legacy = output
types (and show little interest in upgrading).

Best,
Antoine Poinsot

--
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/dbaf0dcf-3a47-4790-b45a-639a22de45b9n%40googlegroups.com.
------=_Part_9349_776609702.1775766686002-- ------=_Part_9348_756496.1775766686002--