From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 09 Apr 2026 12:06:26 -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 1wAuht-0002O0-KD for bitcoindev@gnusha.org; Thu, 09 Apr 2026 12:06:26 -0700 Received: by mail-oa1-f57.google.com with SMTP id 586e51a60fabf-41c47598af2sf2367015fac.3 for ; Thu, 09 Apr 2026 12:06:25 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1775761579; cv=pass; d=google.com; s=arc-20240605; b=aODqrNXl0k0ar3lyuKPBXHci6TWGaECeXMhim8kv786IwR1JqlZDOTUvV/kuSAhcwY Xrb+HbY2SLME9lEACCONCqrc3hzcRD1bSonCvzHY48iZbt3ru/UokrIu45DvHLraEUEb 6E6qVOXUd8SNk0jZLTQkrXDAdIxstSW3xO3+V4QqntjXg4GiWfel/fMPjtsX+s7TF6lN uaLA2nWU1HYLL0nyTwV/W15h9oUKbet7Fxr1kKfnJO4rwNZHmRv0AnaPKvzZQ1YJEbIv CdgwfmjKqYDRtPShTjS5+aT6+1O4V+9rZrmmb9HnjPesmx+vCcuP573yX8KUALe4Ywa9 iEnQ== 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 :message-id:subject:from:to:date:dkim-signature; bh=Og1swalCIYdZRlHpU1Ts0S77KBP6sVPhGHwHr1GolIc=; fh=roqG1kbONTzAhreGEKCkKac/ZAfUQGqXmUANz7+6+78=; b=Dc8HibVlKnfiwGOTk0jdMvCcV5DcJ9pX7vVlCt+e59BcmfRBPRPww2wqEa83c2oQrG WaKBa9udunmeMbgGjpyECxH4Sv8quRqMHRndX/+pDbXdRGDBIOzk7HbV8dVLmq7nCFQ5 fFGQPdAFxKpD4O2RVc0dOl/dwMox58Mdzz41Nc+VhbbJXVm5D03gzsLwnJ8oUA8p2MSW gkAfKNom3nRFvxQhSNikefLv7g8f+KmcSg/0/mDN3ghmXnpfOAiM0/SXYSM6S5JB9fYa ztRXMivqo0S4nZtnTKI95mn80/gVIVf3WPw3soFXSHjQKE8SbhcNQghOWckjrWl+7AXy hXiw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=bRSJu5Bd; spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.118 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=1775761579; x=1776366379; 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:message-id:subject:from:to:date:from:to:cc:subject:date :message-id:reply-to; bh=Og1swalCIYdZRlHpU1Ts0S77KBP6sVPhGHwHr1GolIc=; b=Ug5B4DcLdgwBUOoL0YxbLXOF5knKGA2O/Kp6AKxX2dvsU5yjpQnP4J6LIad8alkD05 PXKPVO+WptwHQKiIQQEnMTTDAkV7kGuprKXq5VS4B3udO36BgEkud47W4b0IhL1/7bOo F5bLQT/i8T2exe4Si8xr+u3Q2d9TJXSed+agSzKJ6Ji8AJqI75Spkgx62SP4tbYkJJzJ 2iBYps8QWusAmuZPShUcf8EbSkjHKrZ5f7vmCpevTitc9uO0rdLfpa0sLa2/Bb88+lWA Ck2f4Or9L8OyUHMEIn9+/q98Y+vCbVrsmU12ULrNAtnpsyPsh9iF22wPSrIXfvC54hFL UqWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775761579; x=1776366379; 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:message-id:subject:from:to:date:x-beenthere :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Og1swalCIYdZRlHpU1Ts0S77KBP6sVPhGHwHr1GolIc=; b=rPScuDqUS6LAifcVGpH3jMr2QtAJS2qgSlkueTTxWj0yEDYxSwlsffvmTOcygqWwOc 1i4ASN6yd8v3Ad0G4NVBvjyyEzLm6q3u8RVHGsoo164UsIupy2UQjp+J5u9C+q4Z6EIx wS1ViF1xfJU+KZ4Q6zVDGSkplHXd5PYDFKcECeL0Brp3ELwmRnsGdngVMXxrJgc6d3TS +KjuPV+8gqCT2VJ19kM8Y2xfrNsA8vK/Avxh47NSlU5xV2p7EivETQnY7WWkqIWj4yGo 9dvmsF2VnuDIworwrnXOLc50kxBnXTSxQykuxjZS/qh21TXmq2DAgbdh/n00FPx2KxjY RhVA== X-Forwarded-Encrypted: i=2; AJvYcCXCOUUvq1gS4jpVPKYhtN5CLFNpgBBd7zirM4J5jnYJmXDiu3fsx50owOPMWT4EWFNvRCkHjbAxSGCd@gnusha.org X-Gm-Message-State: AOJu0YxXAoqpzbR8oMgy/3YcXne3Nxf8am7yZkxd1YM9g88wFPgTRddA jKdYua4N+j88KZkzTdL8QQbLX5xObtaKPgl7uEixs/4WIf22+1bZKGvh X-Received: by 2002:a05:6870:332a:b0:417:1726:9076 with SMTP id 586e51a60fabf-423e10e1dcbmr110266fac.29.1775761579290; Thu, 09 Apr 2026 12:06:19 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiIEh/38GU9YuzX13xuf19vXPATRRld2AEqIJ2HS7jdSVA==" Received: by 2002:a05:6870:e9a9:b0:423:478c:291e with SMTP id 586e51a60fabf-423dd9b07bals88693fac.2.-pod-prod-03-us; Thu, 09 Apr 2026 12:06:14 -0700 (PDT) X-Received: by 2002:a05:6808:c171:b0:466:fd60:239d with SMTP id 5614622812f47-478a0003315mr204336b6e.42.1775761573997; Thu, 09 Apr 2026 12:06:13 -0700 (PDT) Received: by 2002:ab3:7803:0:b0:2e5:dca6:8eb2 with SMTP id a1c4a302cd1d6-2f6d80dd434msc7a; Thu, 9 Apr 2026 11:58:23 -0700 (PDT) X-Received: by 2002:a05:6512:3e1b:b0:5a3:d30b:9575 with SMTP id 2adb3069b0e04-5a3ef906202mr110464e87.14.1775761101672; Thu, 09 Apr 2026 11:58:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1775761101; cv=none; d=google.com; s=arc-20240605; b=hLkzqbYeAblQvVRqJrB1Q7dB2KZD2HiF8R66JcGSwYn7MWJ+Lk+qEObhqgN967stI7 PhG/OHCZuOR//3Yfx6Nmo/5goPR3uLtRMM6PO6wCr+JcdaPXfwyW5xRMO0Qr+epo0IKs mueBJHR+UrTGaxzTLTCiFuyOCKsnktse6VVLIGccx+tczgO35QSDdvxr8135f+bGke5n cORZNLNcq9F+ByC3LuO6olMhJoTKgYJd8NkF1NRXg8jgV6zXJOu6etfq8tuVlukEIEhz /o8BxaKuGNjvUQ439/SR/j4skObtm7aH/5GmX8leVUXcUF0TKkLxaBPoNoXAuj+9UcOw uGTA== 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:message-id :subject:from:to:date:dkim-signature; bh=puLIYfpb7IttuK5nX77fboAh1Zogd4elAwsTomLMaJM=; fh=DMP0F9ULS1guKiqimntQRCN8ZraraesEgQuVcn7F0Z0=; b=gWl76l5RkBfbVSc9w3o1I9qrA8A1c2xb5BP47AiZszTave5/uEJOkGdP/FlGOC13sz rqp2cQjma1BR7DTbY0eg9eOYNA2ikqmd/Iar76s9mV4henkHTihS+cDSrtTIvj2JJdDt P+mvLkFSwa6oi5ZyNa0uz24DA8UJEIQAjutRfbQe1Hk+3eCdNRb11+IdBjWiYv4uhs50 4Me7usC2PCJgto9SH7PlRCodl8fngeSuOz+IG/VwTapBIgPzfWA5/J/NBUC1dVxuCa9I Y8PgkRbefn/6hKMcc/BZ62eB4owE1XTWX3Ktio1y1x08quq6W1L6AhqtYDTfhIvvU1tA 90yg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=bRSJu5Bd; spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.118 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-106118.protonmail.ch (mail-106118.protonmail.ch. [79.135.106.118]) by gmr-mx.google.com with ESMTPS id 2adb3069b0e04-5a3eeec2bafsi8900e87.3.2026.04.09.11.58.21 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Apr 2026 11:58:21 -0700 (PDT) Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 79.135.106.118 as permitted sender) client-ip=79.135.106.118; Date: Thu, 09 Apr 2026 18:58:14 +0000 To: Bitcoin Development Mailing List From: "'Antoine Poinsot' via Bitcoin Development Mailing List" Subject: [bitcoindev] In defense of a PQ output type Message-ID: <0vqF88LoOnY4GiUB4vf-MdeZpTAtR70tokS3cLwt2DX0e6_fD1X_wyhPwWEdIdm6R88AULObIU08CWsb5QfeoaM5c4yXPqN5wHyCrqMCtfQ=@protonmail.com> Feedback-ID: 7060259:user:proton X-Pm-Message-ID: 7bffe897af287e188d3fe9a01eb52f4ad6ac2598 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=bRSJu5Bd; spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.118 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 (-) 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.