From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 15 Apr 2026 11:47:49 -0700 Received: from mail-oa1-f57.google.com ([209.85.160.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wD5HA-0000ui-G9 for bitcoindev@gnusha.org; Wed, 15 Apr 2026 11:47:49 -0700 Received: by mail-oa1-f57.google.com with SMTP id 586e51a60fabf-423306870bdsf13410544fac.3 for ; Wed, 15 Apr 2026 11:47:48 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1776278862; cv=pass; d=google.com; s=arc-20240605; b=jom5JDJUTnXqUupnW2BjPsdpmM2+VoxvutijTxAjZspSbEuzxIT9t7QW6X9o4PTfNP 8qYRSKxqxnQNUTnKpbr4E7/0iTW5PvzOidwtr5Rcq2pt8xbZa79GtyEnaASa1t+P4iWz IJ/o9+97wc4aDE55xMslNjGsXxqGRoRUPsom76/D6gj5MhNSHsdFHCAzImcdy7wFLwQj DcCrCPYZhotsTuAw9knWtEX78bTjkdf03uNWqaOvfS9IrYAtG/0AF/YmRv3zXQ7Wbv2V JYHRy4D5EWee+tP1x7set9TyASNZ+hpAN8jSQ8RvnKds9ICRzalOgSeBaxRAPJHNBtp3 zxMA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=CE8QfagXQTXCqN45ywL4FCNaRlB+aPrPHQvXaOdniuk=; fh=3iMhbFvPpCS9cT6OFhEGJ8FZlqxFsABP2jId9VfI67A=; b=A8QbsVctZcOfpqwDH77jGTv+NaQoxjeFm+C5txW7EU9rutLbVnLamP7Nh5uUOYLtp2 3XDXAT5h3xzcD0DZL6j9EPXW22TtWtetxTua9S5hmmYvMCdikvtgeEQrzA7gnRoufp2P TIF0O/SnkE6YH09Si7JTW+3IhK6f804N/vcIMj/fWplcBlYl7Gd1sNv3uxtz4eNLSmxp vXpRpamNNBFmw1ol4ziV3/H/bgqThfbkfSLTYm9N3w0R45pQkBOssmSI7Vl77N6QLdNU j4rqgMtNqz9xXCetJJMk8eqSRnsaD9QekSfsIvNzm0GazulskXc1XSatsbYrU8rOuh7h Tp8w==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=d68xMh1J; spf=pass (google.com: domain of darosior@protonmail.com designates 109.224.244.16 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1776278862; x=1776883662; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:from:to:cc:subject:date:message-id:reply-to; bh=CE8QfagXQTXCqN45ywL4FCNaRlB+aPrPHQvXaOdniuk=; b=uIinDFpvMpxWoCEgQyVD8IPb6B8mBC5WQlsiVVc5qiK60iz1GsBC+cmIbrQtt/YKWr qyKuZ6eoJz+V0r7lqFiIuUBYQ82a/fR+x9FNWQEOieSxtIwoHwlsuqQ5QKaKp4nyGf04 YnqWbjhZaRtPLODBccMkWfM6YsI/0RTCHeayquAzzPbCLr/5kq+XX00Ycq9qJA5Hr1bj UxeTMKYJrT7upPMeoQZ82vUsgL2ib+VJoAQacls1ri9CRDILFOXhogI+DrWQ6ikjYBpt 7rBwCbLu95xlSQYaDwPf7xXNfGQVD34Phg3G2FvjDJF7LgmSR6DQEu+T+od0bYBp5pxM nhRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776278862; x=1776883662; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=CE8QfagXQTXCqN45ywL4FCNaRlB+aPrPHQvXaOdniuk=; b=S2oybRwOCgYYbSjMoc5FymLxP4Ki1CfXZVsh0IHrcVef+73hluCDeXFgDzGvHSFSk4 royH7f+GOHpQ9vhQhfZVzXakd3mXti/Kcyj02eprK7KDfymGfuwHeBGMqyhMJYGRwghK OYwlYZOb+sX7NMfpNo8TqQUjJ68eojr4c4RU/MGdKO29Dm7+pqyHmAWMfGlKNuhQ1FZr P5OhHQo6EnaKJJvhpwluaqwq3vMfRmSWyErHyUkSiSI7RgPDDnLO4C5n7qoD6/IwO0Hb vcMZRHW3IQ4KSsfTFRgZziwDYabaFwJFIoZi8SoeD4/2N2HF0tEwR7+uLpmSCfY8XFx5 1OXg== X-Forwarded-Encrypted: i=2; AFNElJ+5AhLoKNBLf/0ownaWteesVV0Nm2IPr7NmNgSoa7tfcuoOvZzf9DcOeJ+KZOZFCqV1k1lmcijbzqnm@gnusha.org X-Gm-Message-State: AOJu0Yw9cRAGHzymwh8/KPxOBVMJvc0EvBwuFMmyQMY1Z1KtqJzrtVJe 8cBlUVFPUINpxh4tzc7wpMU9qx3SYca8YMKxmmxaGDovtbpy/f0kBLzz X-Received: by 2002:a05:6871:a841:b0:417:6237:cf7e with SMTP id 586e51a60fabf-423e0e5d2bdmr12824152fac.8.1776278862032; Wed, 15 Apr 2026 11:47:42 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiJ6nrrdVKKC6cw34406N+SjmgdOzYEKLSILH7gkybhCEA==" Received: by 2002:a05:6870:7992:b0:422:f32a:6626 with SMTP id 586e51a60fabf-4280c56abb0ls81229fac.2.-pod-prod-09-us; Wed, 15 Apr 2026 11:47:36 -0700 (PDT) X-Received: by 2002:a05:6808:4f09:b0:46a:c98c:bfe9 with SMTP id 5614622812f47-478a0305255mr11840452b6e.40.1776278856598; Wed, 15 Apr 2026 11:47:36 -0700 (PDT) Received: by 2002:ae9:f80e:0:b0:8d6:1bc4:a7bc with SMTP id af79cd13be357-8e4e75bc967ms85a; Wed, 15 Apr 2026 11:15:21 -0700 (PDT) X-Received: by 2002:ac8:598b:0:b0:50d:a7d9:d9af with SMTP id d75a77b69052e-50dd5c9fc70mr318156371cf.53.1776276921214; Wed, 15 Apr 2026 11:15:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776276921; cv=none; d=google.com; s=arc-20240605; b=iYSYgAPlwA5DcoZDri0RYXPYyghYth6LtDGEMjVwr56bRC+v94X0jZXLwR7fwSlIZh vzFm5I3nc9FHyTn5r1WFy2W9EEgp/SngIqoociCFERNatuZ4v1ejHM1FBZfDG3V/REDU 3JrVcSM99R0noNDFekIg49rq4ntskMEBqN68YQ3AAYbOaLnJhXi6YEAHc6vTF/GnLQDn UFjn/+51pOqyQTvlioOrsiFH405Z2qjKpBKKIYA5KxXxNzuTI4D78YiU/VN/pReYA5Ui wti+OiRSHhAZAcaF3DXX0hNmSDX+AbNGJNTmaA8ZVMUb4nMXszO19aeG8hUpZabuptnE c6Aw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:dkim-signature; bh=gxc0JxAtZLew0f4Psn1m+U/u5nUq1WyIflNUVfjE+eo=; fh=NHiC1CbEDALfG5/ISsq3XuaO/IYiNdqCOmsmqF9WL6o=; b=T9RMv2LjPzgJo/PkEIZkPRFaGmdIsXdhtyUgYH7YhRetUzKP7ceSO1MVBjTv0TvbwF 4myvSfG1+x7ZqGSGoTgJB8WF3MCtdFH4tZlJxY7G6LMZux/YaGbolLQ3DueerIv+AB84 2nhy0xcH6BME0WAsyglkRRRIoZWifI06mGvTYhHDtS6m6eTlHKVTXF4o48vADz4HzeEw eN7eWsWWX2SZVXO70LblgH5FRTS2JWuQ9LNijQHiUHe8J/7Z3U/MmoucIcZ26HRrAbsW QsWofN4qt1cucoHEUeMnssrscNQo8AnO1LPmrcdFT4ePZDrHFlBNzI5WtWDDCxWjvG20 g15g==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=d68xMh1J; spf=pass (google.com: domain of darosior@protonmail.com designates 109.224.244.16 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-24416.protonmail.ch (mail-24416.protonmail.ch. [109.224.244.16]) by gmr-mx.google.com with ESMTPS id d75a77b69052e-50e1ac13454si896821cf.0.2026.04.15.11.15.20 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Apr 2026 11:15:21 -0700 (PDT) Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 109.224.244.16 as permitted sender) client-ip=109.224.244.16; Date: Wed, 15 Apr 2026 18:15:16 +0000 To: "dplusplus@gmail.com" , Matt Corallo , Olaoluwa Osuntokun From: "'Antoine Poinsot' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] In defense of a PQ output type Message-ID: In-Reply-To: <0vqF88LoOnY4GiUB4vf-MdeZpTAtR70tokS3cLwt2DX0e6_fD1X_wyhPwWEdIdm6R88AULObIU08CWsb5QfeoaM5c4yXPqN5wHyCrqMCtfQ=@protonmail.com> References: <0vqF88LoOnY4GiUB4vf-MdeZpTAtR70tokS3cLwt2DX0e6_fD1X_wyhPwWEdIdm6R88AULObIU08CWsb5QfeoaM5c4yXPqN5wHyCrqMCtfQ=@protonmail.com> Feedback-ID: 7060259:user:proton X-Pm-Message-ID: c0394afc9d35bb72e809121d71e255771e399564 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Original-Sender: darosior@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=d68xMh1J; spf=pass (google.com: domain of darosior@protonmail.com designates 109.224.244.16 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: Antoine Poinsot Reply-To: Antoine Poinsot 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: -1.0 (-) D++, Laolu, Matt, Thank you for your responses. Since you raise related points i'll reply in a single email. I think the disagreement boils down to what we are trying to achieve. The debate on output types is downstream of this, so i think it's worth pinning down the goal(s) first. My view is that we should mitigate short term risks to consensus in the event CRQCs never materialize, and minimize the amount of BTC (as well as UTxOs, ideally) at risk by the time they start being practical in the event they do. And, importantly, do so without creating more risks to Bitcoin's perceived value. This explicityly rules out some theoretically possible scenarios, which i believe can't be realistically addressed but are fortunately extremely unlikely. Another thing i'd like to address is how some replies appear to interpret my post as a defense of BIP 360. I think their approach of keeping Taproot's Merkle tree of BIP 342 Scripts is a fine design, but my argument applies to an output type that enables a hash-based PQ signature scheme, and preferably disables EC opcodes. BIP 360 as it stands does neither. Both D++ and Matt pointed out how my argument that introducing the PQ scheme in Taproot would create perverse incentives with regard to the later decision of freezing could be addressed by using a new Segwit version for PQ-Taproot, with a social expectation that the key path of such outputs may be disabled. Fair point, but i still think this is a weak guarantee. If usage of this new output type became popular for unrelated and unforeseen reasons, this could make disabling EC spending paths as murky as for regular Taproot. Another argument someone gave me in meatspace was that users of PQ schemes would turn into supporters of a freeze nonetheless, once they obtain the safety of a PQ output type for their own coins. That's plausible, but far from a certainty. I don't see much push for disabling the SHA1 operation today. And even if the share of BTC protected by EC operations was substantial enough to be a systemic risk, users of a PQ output type may prefer some amount of risk to the certain undermining of their asset's value proposition. Laolu, in response to the three futures i laid down that i think we should be optimising for, you pointed there is also a possible future in which there is classical advances in breaking the ECDLP problem. Sure, but i don't see why this should suddenly become a future we optimise for. Both Laolu and Matt pointed (in different languages) that a PQ output type is not mutually exclusive with a Taproot embedded version. It probably wouldn't hurt to also introduce a PQ scheme inside Taproot, unless we think that making the take-up of CRQC outputs publicly visible is a desirable property. But it's not clear to me that it would achieve much next to a PQ output type. Presumably, concerned large holders would favour the assurance of an actually CRQC-resistant output type, unless they believe the CRQC risk is lower than that of leaving their secure signing environment *and* they give credit to the social-signaling claim that such Taproot-v2 outputs will have their key path spend eventually be frozen. Same for laggards, why would they bear the cost of upgrading to a Taproot-v2 output if they assess the CRQC risk to be low enough? And once they believe it is high enough, why not use the CRQC-resistant output type instead? It seems to me that outside of newly created wallets, the case for a Taproot embedded PQ scheme is stronger *in place* of a PQ output type. If large holders have to use it in order to get access to a PQ spend path, then we can reasonably expect them to keep using the EC spend path until it gets disabled, thereby reducing their onchain footprint. However this alternative does weaken the risk mitigation(s), because one would have to believe the key spend path actually gets frozen eventually.. Matt, you stated the (only) goal of a migration strategy should be to enable the maximum number of coins to be retained by their owner, and that this is only possible by disabling EC spend path(s) and (i guess hard-)forking a ZK-proof spend path for those fortunate users that happened to use a common key derivation standard. First of all, this is only true for those owners that are somehow unable to make a transaction until the advent of CRQCs, as any other owner could simply migrate to a PQ output type instead. And therefore, this is also incompatible with a higher-version-Taproot-output design that allows users to opt into a future EC spend path(s) freeze. Which are you arguing for? More importantly, i think your goal statement goes to the heart of the issue. Maximizing the amount of coins to be retained by their owner is of course desirable, but it can't be the only goal. Especially if it comes at the cost of consensus changes that risk burning other users' coins. Finally, Matt you also asserted that a PQ output type alone is not a migration strategy since it would not achieve much. I think that if you spell out the argument behind this statement, the case is actually weaker than it seems. The burden associated with using a hash-based PQ scheme would certainly slow down adoption for those users that have less at stake, or whose usage patterns would be particularly impacted. But it's only natural that holders with different stakes and risk profiles make different risk assessments. Each may migrate to the new output type as the assurance it provides comes to outweigh its associated costs. Best, Antoine On Thursday, April 9th, 2026 at 3:06 PM, 'Antoine Poinsot' via Bitcoin Development Mailing List wrote: > 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 argument 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 outputs. > > First of all, it's important to clarify what we are trying to achieve. 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 network does > not survive. Not all plausible futures are worth optimizing for. For instance, > one in which PoW ends up broken only a few years after EC crypto, or one 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 schemes 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 "break 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 this > category. If they became the only safe option available, it would certainly make > Bitcoin a lot less attractive. But having them around is good risk mitigation > *regardless* of whether a CRQC emerges. > > It's often argued that a freeze will be necessary anyways, therefore we might as > well disable the Taproot keyspend path simultaneously and simply introduce 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 scheme > available and 2) freezing vulnerable coins. Yet introducing a PQ scheme 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 consensus on > a future freeze. Frankly, i do not believe the latter is achievable, let alone > at this stage with so little evidence that a CRQC will materialize anytime 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 decisions would > necessarily delay the deployment of a PQ scheme, unnecessarily exacerbating > risks whether or not CRQCs become a reality. > > Another drawback of the PQ output type approach is that it would make those > outputs distinguishable from Taproot ones, which is suboptimal in the event that > a CRQC never materializes. But i would argue that even in this case, the cost is > minimal. The users most likely to adopt PQ outputs today (those securing 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 "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/0vqF88LoOnY4GiUB4vf-MdeZpTAtR70tokS3cLwt2DX0e6_fD1X_wyhPwWEdIdm6R88AULObIU08CWsb5QfeoaM5c4yXPqN5wHyCrqMCtfQ%3D%40protonmail.com. > -- 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 email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/b1Rnhsv35QTZwTeWM9R6Z9MGYw950zAXhs1QCuavxI64Y5CmSkYSXEP5bZgI3l1OY6V7PfBtBBAjXF1ACMznCg4VNrHJ1rMTD7qQM2hgtz8%3D%40protonmail.com.