From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 09 Apr 2026 14:24:59 -0700 Received: from mail-ot1-f61.google.com ([209.85.210.61]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wAwry-0003fb-7s for bitcoindev@gnusha.org; Thu, 09 Apr 2026 14:24:59 -0700 Received: by mail-ot1-f61.google.com with SMTP id 46e09a7af769-7dbbae0ce57sf342026a34.1 for ; Thu, 09 Apr 2026 14:24:57 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1775769892; cv=pass; d=google.com; s=arc-20240605; b=VKpBPrFLE9+vczCzB61Qub5ixNvQCvgUZOi57QYCXDve3ZkPhD16B/kV7Xdg1fRJfl 7PuxoBLVqKzV/WYHWgAgk/NrZqMQugWFsJs76/gRMjusM6HdQnjuI2YeCTn6QX4Mq77/ xRtV9gj2XhX5qqxubZ0fxJEVrGxizDuJBIikO2mKEpEsjqkcS+u40qsMXilKvFxfk9XA UluozkzmnQmRvWr3Ieu3oN0OjtQT5krmfKVvn5HteAubAJRM1mS+HnaUFuq8eZTjM/+u YCak2lmF75bw28leIxj4eoziTXbJzjdG8kRxpQREJayfff2TkO0zpf0Qgy8Mj+pFNoJE Jj6Q== ARC-Message-Signature: i=3; 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:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=NK6OhJ35K7GVPMlEzPx0PBIOLvnCxKjR6Xzod+XTyHc=; fh=PW5KbZxtmPwqqgguDziRZ+KtvyoTeJ1PepdQHxdfWkA=; b=O6zNT/zPphqwLgl6soQOSrjKFy/iDp+d+uowT68hmI+WnWtmTuqkDpFOe7b/gh9zxb BVBnGzrNjr/CS7KyjmYenFT605le6mTwFeE4+IUcCTVaZwouNbrtTeHE+vCBX5Xolwul kEKHUcl+02lCybGcXSKthdyM+LW5ExQ9Szxliqvx3Aypk98YKKa0ra8XCR0Xdte1WecS 3T+OU1YFmyApmITQeHDexH43Nwb7GTlS0nnqL/zxc3yuN1iCAGoN9Y24xRung4m4E5WY uch4B8aYcYOLql0Zx1YhWh8RGrhnaD2i6uhGN9Nnz1OYbMqdzo9rBYsxucGU1kyEHue3 85jg==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=UmH18FG+; arc=pass (i=1); spf=pass (google.com: domain of laolu32@gmail.com designates 2607:f8b0:4864:20::b133 as permitted sender) smtp.mailfrom=laolu32@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1775769892; x=1776374692; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=NK6OhJ35K7GVPMlEzPx0PBIOLvnCxKjR6Xzod+XTyHc=; b=lX/W2qKp3H3JGc+boaEaBJQjDjdqAmDY7Yr5HvU0YaeHMdtiZ6FGjwWww3kDxUR2eo a0POgEF9QMOQ7FXFb1ZzBiR7eCTT16XhWfBl9PCPD7qz45Uc/xkBRC45OxIzItrrspVI XA+tn9IQ0y93XiMSICnTuqvlwGJyl3wZ25A3lURRSsxd6qazmqXlz/vrRRuM1b9lt0eR o0kHgSlsD1G8wnBVudnAFkEtGJpLYvPC5Uc/S9r28mFpiLNPjC4VoH/IOJhDmDGdHop4 bucssJZ6F1CJjNYq1VaeTAawauyV5cDhr99MGnBqf8s1VTmbd8THNyQEyG2O1YNfWigh OJsw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775769892; x=1776374692; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=NK6OhJ35K7GVPMlEzPx0PBIOLvnCxKjR6Xzod+XTyHc=; b=mHJhB2DudLn/ilL7q86dmC7IKZv9HSK7VNjQIlhxbF2an8lRJlX6i83XpGlC4zruCI ESN5qe9dxxiqOtVTaS6FF/CvVGM+xH9Q08H4VlakSP6qYSA7INE5IA8vyr+63RZLvmS1 Oa0KNiHuF2Ra1B9Tn8ex8jfABUDy7Cs/bK9SKvmKklqn1Ia7Ho2DAE6/Va0is1dEB/PZ VMNu7oekiwfsVjZPD9gOsrA61QAjlBB23SN7jP2JgjuRv5b6DNycVVukpVFtMEXw1+p/ Tjxna6bWs8CfuPxPy0KVqVT9lM9mAhCEI8CFEwyyKcirDQB3LFYzK0tlCr2Fqrpe8QU1 p3xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775769892; x=1776374692; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=NK6OhJ35K7GVPMlEzPx0PBIOLvnCxKjR6Xzod+XTyHc=; b=oI+0dLHjPUgwN7IollcZcskZTin1SFEKSO5LM0jUwXaPimytE1UmeUbHf91ijxSKVa nfgel6Te8eBrqHGEH+/hDvvg7z256VpJDVuMc1U6Ug9vguMNvEuwxHuAF6levmM71ZPi UUq1Y64EkhSm5X/QORVvwV5lh9C/UU9eAqWNmyzYsyr+fm/tc6m0+r0IRE53cjS/ZCO9 q4UGSdqosBT1Drwg+TaF12Y10zQo6qOjbeQX2u9BAltXpv+YSHXsBmiO3gfogcaW7Wtz AcdwNH9bzL2PHUZ6GdXH37/Vq+oNqAMP1S1yeUtaPKInFpzW9IefezqZWV6nCjsi3IhI sSFQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AJvYcCWfJBNowZE2/oTSpLT+eSd1SQmk7zPGW8NW1wbmPtf3AkVt9sfcSXfzb2p69Gpsl7mJD54YnqNs75Ap@gnusha.org X-Gm-Message-State: AOJu0YxlHM9MCfwswfPJrM1ze/nO/tI++bakQgazGH7OPNv/yKu6khLG Vb6/0/kao09UJrJwezji+VokgXQj4PNeZ2Qs8orZYoXtdhl8d87pEbCQ X-Received: by 2002:a05:6830:25c2:b0:7d9:d3ea:10ec with SMTP id 46e09a7af769-7dc2a1d605dmr5425a34.6.1775769891617; Thu, 09 Apr 2026 14:24:51 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiKh/qb4Wc7xznHqaxDPFSzeyp60qkuC0J4QXsiGW1bFnw==" Received: by 2002:a05:6870:70a0:b0:41c:6ad4:3efb with SMTP id 586e51a60fabf-423dd989597ls165537fac.1.-pod-prod-08-us; Thu, 09 Apr 2026 14:24:47 -0700 (PDT) X-Received: by 2002:a05:6808:19a3:b0:467:1e5:6769 with SMTP id 5614622812f47-4789f900cacmr527838b6e.45.1775769887140; Thu, 09 Apr 2026 14:24:47 -0700 (PDT) Received: by 2002:a05:6808:628c:b0:46b:22a1:35fc with SMTP id 5614622812f47-4775d81d877msb6e; Thu, 9 Apr 2026 14:17:33 -0700 (PDT) X-Received: by 2002:a05:6870:b621:b0:423:e06:745e with SMTP id 586e51a60fabf-423e1128505mr286588fac.34.1775769453061; Thu, 09 Apr 2026 14:17:33 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1775769453; cv=pass; d=google.com; s=arc-20240605; b=jFvTpf3pAU77UDvNMM4cDOJW2GxA68WkRGLKClGpI8mcMMU+Qr1Xg6HrA+5t9k7YzX +U5w+AUOf+3u06O5cnbFdC0gJ414A4NHerOa0GG++6og2ij+EwdkDIOtbiEWFIB4UCR6 eNmRfik4Sp99fm27txKL02e4JKMmsjN6ajOPtNEMom5OHnu0Ra9qdc4AS+S4+cvy4LK9 eYTkf4uxf/hw27RZQ9znGkRabagX7d2IKZxuijug9D4QMchYRFywE/9xSn+dMR+Z6VGH TvQeVonDbcVevGhImS+/T3miS0rXZ6ArFw4FT5guHP0iaPM3F8mepR0gqhztgTM85iR6 op9Q== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=tzoVF3x2h8UJLSFfj6fUKj2N44iGqSVHT6tlv6cjDDA=; fh=m2IwlnuMmP6ceRgqI8U7RCh8Dkd3VeWlWEfxse0Wcvc=; b=IgG10v2Kir2wOgQ73RC+OPSPINxMw73CWuJftqoz1t24LDPxm5Yzm5LIJj9F3RBy0i 0bDtcA6+Gg3p7CCCodj9PK3x1pk4VH7lKw0nvkYQrlAc/pF5e+5DXZ+JItt9fKHeVp8X 0TBX02KOt2t/++4ffNf4BFxZkwqy+w1EEAgSnpJlPPN7cHPMGAsHpg3V5spHW3HkiqQ8 DUl/bEp/QpQt020aYajUmJgf1VqEJwhQXNDIg6qZR0QJmxyO3oVXGGIdNAxEDuiUnIA3 l/n38PlXeC+D4YpXLjvjU7M7NoIViNKevEtZmPebXjRjHSpU0E8Xy04DflMjwWkdniDB /4Ag==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=UmH18FG+; arc=pass (i=1); spf=pass (google.com: domain of laolu32@gmail.com designates 2607:f8b0:4864:20::b133 as permitted sender) smtp.mailfrom=laolu32@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-yx1-xb133.google.com (mail-yx1-xb133.google.com. [2607:f8b0:4864:20::b133]) by gmr-mx.google.com with ESMTPS id 586e51a60fabf-423dcf9a49bsi26552fac.0.2026.04.09.14.17.33 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Apr 2026 14:17:33 -0700 (PDT) Received-SPF: pass (google.com: domain of laolu32@gmail.com designates 2607:f8b0:4864:20::b133 as permitted sender) client-ip=2607:f8b0:4864:20::b133; Received: by mail-yx1-xb133.google.com with SMTP id 956f58d0204a3-64d5a7926cfso1378523d50.2 for ; Thu, 09 Apr 2026 14:17:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1775769452; cv=none; d=google.com; s=arc-20240605; b=jKSik3To8riXK2oAB2olmZmK6sfmpMR7DSg50Zk8Rd+haQfUG17fXxq2HXtmat3ptb n+dgUoTnOOVdL7R9ZaoOMPDxdOUxHCnFzXCLhHxOMXkfoToRLSJvqCShIUqV7DpOZavL BIsB3n9rtWucFs0jeTix6/0jDef0h0ofhWP3hbDDGc2DMlBDFeic7wtknSK3qkioKhYz 3MIspg1I3sw9PWGCMwYQlTcZ4Cf64LwCIS4S44UItqnTq94HPygCHoQPNZKC6cxVVrJK GpkvB+0ZmGHgp7A8eO4MMdEM4u4esFqOS7Hzes6dG5q1hB+dkdkcnFcQIW2iSdrgcAFk Ftfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=tzoVF3x2h8UJLSFfj6fUKj2N44iGqSVHT6tlv6cjDDA=; fh=m2IwlnuMmP6ceRgqI8U7RCh8Dkd3VeWlWEfxse0Wcvc=; b=Rfy7IcgtapMFyYxNldkkjwh7yVoeatDol78oRmjGhYYCMXpZWXOzS9oo625CIjuLt3 SaAiJeJYSllq4UnTAcsxduBoZnkMLETupJelbAksQLUh54Ji1ItEeyiRSWF+KyTn8xmI 1vVFmApI+azIki4N73gIIFo5FMInr/VGAR4DWO5Ppmuvr9obldeKa+wDHbGFX5eR4n9e Dd1Vy5pNXJShFKG5JDj3N5mN1zWX4HDcBeizBT6TMexqyiAPwOSQvpS2uoSbjLEhI3/O S8e7P7UKuHQu85Vdmfd+vbiUBJntyLoUX0fgEyITCXEIw8t1nQRgUJnmjjyzzTAN+N42 ufoA==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: AeBDievb1imCR4+FrpWzsARzB3yL7Rilx/KfylQ/fvQWJnslVSZvb+zPmhYjDgfryOH cgDlyAE8jF4/KSuyVSh/j+73g+7417FBoQUGjBbaphp0LeqDMJatzvFYKPC6GoTW9nrAgzstSt3 KTACJn4ZCZ+elB4pdjXaue+E+KVg1K1JB9jbAbU1KBpEbUub+K29n9ODnVZUCsiIE+7KEOuNV9L mlH5RXkTmdf9A97ai6ZgCEm+MbhKizC5cvs2QbPqTkCsS42Pom6gNPoqsTTH+nLe+PVBb6FeopG NuJ8yxEsjfXK2GqY+ulcGOt93HBR84oaQ3b1TYWKgTFDv4ShMhA= X-Received: by 2002:a05:690e:1448:b0:650:789b:a3c with SMTP id 956f58d0204a3-65198b564d9mr609740d50.35.1775769452335; Thu, 09 Apr 2026 14:17:32 -0700 (PDT) MIME-Version: 1.0 References: <0vqF88LoOnY4GiUB4vf-MdeZpTAtR70tokS3cLwt2DX0e6_fD1X_wyhPwWEdIdm6R88AULObIU08CWsb5QfeoaM5c4yXPqN5wHyCrqMCtfQ=@protonmail.com> In-Reply-To: <0vqF88LoOnY4GiUB4vf-MdeZpTAtR70tokS3cLwt2DX0e6_fD1X_wyhPwWEdIdm6R88AULObIU08CWsb5QfeoaM5c4yXPqN5wHyCrqMCtfQ=@protonmail.com> From: Olaoluwa Osuntokun Date: Thu, 9 Apr 2026 14:17:20 -0700 X-Gm-Features: AQROBzBEF0JFbq89fjmUFCdQ7FuedqGQoTiQ-n3Ikyp5wxJbbhVOzQ4cCuGjeyI Message-ID: Subject: Re: [bitcoindev] In defense of a PQ output type To: Antoine Poinsot Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="00000000000068d80f064f0d8be8" X-Original-Sender: laolu32@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=UmH18FG+; arc=pass (i=1); spf=pass (google.com: domain of laolu32@gmail.com designates 2607:f8b0:4864:20::b133 as permitted sender) smtp.mailfrom=laolu32@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.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 (/) --00000000000068d80f064f0d8be8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Antoine, TL;DR: "=C2=BFPor qu=C3=A9 no los dos?" IMO it isn't really either or re a new PQ output type vs disabling certain vulnerable spending types with various flavors of a pq secure escape hatch. Adding a new PQ op codes and/or output types would be a precautionary soft fork (ppl to migrate at their leisure), while disabling certain spending paths w/ an escape hatch would be an emergency softfork. Even in the face of the emergency soft fork, PQ safe signature types are still needed, otherwise you don't have a "safe" place to sweep those vulnerable outputs into. Also note that it's possible to create safe escape hatches fo= r non-Taproot output types as well (assuming a hash function was used to derive the private scalar from a seed, commonly BIP-32). IMO Taproot (in addition to a new type ofc), is still an attractive target as there's already so much wallet+signing infrastructure built up around it. S= o far the newly proposed output type variants seem to keep much of the bsae o= f Taproot which is great, as that'll speed up adoption, but we've already see= n first hand how long it can take a new output type to be adopted. > I think there are two futures worth optimizing for primarily: There's also a third future in which there's some _classical_ advancement i= n the ECDLP problem, that prompts a move away from EC crypto even without an actual quantum attacker. > i think we should separate the concerns of 1) making a PQ scheme availabl= e > and 2) freezing vulnerable coins 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. I totally agree that a precautionary fork and an emergency for need not be tied together. The technical question of which signature scheme(s) to add is muc= h more straight forward than the politically tinged question of which output types/utxos to disable spending for. IMO an important reason to have background development on the "PQ rescue" fork details is that invariably there'll be laggards in the adoption of a PQ output type even if it was made available _today_. Consider how many exchanges and custodians rely on variants of HSMs for secure signing. If we look at popular offerings like AWS CloudHSM, they now have support for secp256k1 [1][2], but AFAICT, that was added only around 2019 or so (can anyone confirm?). Taproot has been active for many years now, but because it uses a bespoke signature type (on a relative basis), major providers lik= e AWS don't have _direct_ support (tho one could prob emulate it with a Nitro Enclave). Even if these popular HSM providers had support today (IIRC AWS KMS added ML-DSA support last year, but not SLH-DSA yet) for the NIST PQ schemes, it would likely be some time until they added whichever variant(s) (eg: composite hash based, hash based with non-standard params for smaller sigs, lattice based variants that support BIP-32 hardened derivation) that Bitcoin selects in the end. -- Laolu [1]: https://docs.aws.amazon.com/cloudhsm/latest/userguide/pkcs11-key-types.html [2]: https://docs.aws.amazon.com/kms/latest/developerguide/symm-asymm-choose-key= -spec.html On Thu, Apr 9, 2026 at 12:06=E2=80=AFPM 'Antoine Poinsot' via Bitcoin Devel= opment 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 o= n > 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 scheme= s > that > maintain today's properties can be designed, vetted and adopted, and th= e > 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 th= is > 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 introduc= e > 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 anytim= e > 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 decision= s > 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 > 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-MdeZpTAt= R70tokS3cLwt2DX0e6_fD1X_wyhPwWEdIdm6R88AULObIU08CWsb5QfeoaM5c4yXPqN5wHyCrqM= CtfQ%3D%40protonmail.com > . > --=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/= CAO3Pvs8zjQr%2Bn2OnJ1J3M%2B%2BOtx73YNrJW-g9ZCJdOx%3Dq7aixKA%40mail.gmail.co= m. --00000000000068d80f064f0d8be8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Antoine,

TL;DR: "=C2=BFPor qu=C3=A9 n= o los dos?"

IMO it isn't really either or re a new PQ outpu= t type vs disabling certain
vulnerable spending types with various flavo= rs of a pq secure escape hatch.

Adding a new PQ op codes and/or outp= ut types would be a precautionary soft fork
(ppl to migrate at their lei= sure), while disabling certain spending paths w/ an
escape hatch would b= e an emergency softfork.

Even in the face of the emergency soft fork= , PQ safe signature types are still
needed, otherwise you don't have= a "safe" place to sweep those vulnerable
outputs into. Also n= ote that it's possible to create safe escape hatches for
non-Taproot= output types as well (assuming a hash function was used to derive
the p= rivate scalar from a seed, commonly BIP-32).

IMO Taproot (in additio= n to a new type ofc), is still an attractive target as
there's alrea= dy so much wallet+signing infrastructure built up around it. So
far the = newly proposed output type variants seem to keep much of the bsae of
Tap= root which is great, as that'll speed up adoption, but we've alread= y seen
first hand how long it can take a new output type to be adopted.<= br>
> I think there are two futures worth optimizing for primarily:
There's also a third future in which there's some _classical_= advancement in
the ECDLP problem, that prompts a move away from EC cryp= to even without an
actual quantum attacker.

> i think we shoul= d separate the concerns of 1) making a PQ scheme available
> and 2) f= reezing vulnerable coins By contrast, there is a much stronger case
>= for introducing a PQ scheme in the near term purely as a risk mitigation> measure.=C2=A0 Coupling the two decisions would necessarily delay th= e deployment
> of a PQ scheme, unnecessarily exacerbating risks wheth= er or not CRQCs become
> a reality.

I totally agree that a pre= cautionary fork and an emergency for need not be tied
together. The tech= nical question of which signature scheme(s) to add is much
more straight= forward than the politically tinged question of which output
types/utxo= s to disable spending for.

IMO an important reason to have backgroun= d development on the "PQ rescue" fork
details is that invariab= ly there'll be laggards in the adoption of a PQ output
type even if = it was made available _today_.

Consider how many exchanges and cust= odians rely on variants of HSMs for secure
signing. If we look at popula= r offerings like AWS CloudHSM, they now have
support for secp256k1 [1][2= ], but AFAICT, that was added only around 2019 or so
(can anyone confirm= ?). Taproot has been active for many years now, but because
it uses a be= spoke signature type (on a relative basis), major providers like
AWS don= 't have _direct_ support (tho one could prob emulate it with a NitroEnclave).

Even if these popular HSM providers had support today (II= RC AWS KMS added
ML-DSA support last year, but not SLH-DSA yet) for the = NIST PQ schemes, it
would likely be some time until they added whichever= variant(s) (eg: composite
hash based, hash based with non-standard para= ms for smaller sigs, lattice based
variants that support BIP-32 hardened= derivation) that Bitcoin selects in the
end.


-- Laolu
[1]: https://docs.aws.amazon.com/cloudhsm/latest/userguide/pk= cs11-key-types.html
[2]: https://docs.aws.ama= zon.com/kms/latest/developerguide/symm-asymm-choose-key-spec.html


On Thu, Apr 9, 2026 at 12:06=E2=80=AFPM '= Antoine Poinsot' via Bitcoin Development Mailing List <bitcoindev@googlegroups.com> wrote= :
Many of us app= ear 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 argumen= t in
favour of introducing such post-quantum signatures as a new output type ins= tead,
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 thre= at to
the network, there are scenarios, however unlikely, in which the network do= es
not survive. Not all plausible futures are worth optimizing for. For instan= ce,
one in which PoW ends up broken only a few years after EC crypto, or one wh= ere
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
=C2=A0 properties of a Bitcoin network relying on classical cryptographic =C2=A0 assumptions;
- a CRQC materializes on a long enough timeframe that PQ signature schemes = that
=C2=A0 maintain today's properties can be designed, vetted and adopted,= and the vast
=C2=A0 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 mitigati= on
*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 schem= e
available and 2) freezing vulnerable coins. Yet introducing a PQ scheme ins= ide
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 consens= us on
a future freeze. Frankly, i do not believe the latter is achievable, let al= one
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 t= he
near term purely as a risk mitigation measure.=C2=A0 Coupling the two decis= ions 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 co= st is
minimal. The users most likely to adopt PQ outputs today (those securing la= rge
amounts of BTC with a small set of keys) already have vastly different usag= e
patterns from Taproot users: they often reuse addresses and use legacy outp= ut
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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/0vq= F88LoOnY4GiUB4vf-MdeZpTAtR70tokS3cLwt2DX0e6_fD1X_wyhPwWEdIdm6R88AULObIU08CW= sb5QfeoaM5c4yXPqN5wHyCrqMCtfQ%3D%40protonmail.com.

--
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/bitcoindev/CAO3Pvs8zjQr%2Bn2OnJ1J3M%2B%2BOtx73YNrJW-g9ZCJdOx%3D= q7aixKA%40mail.gmail.com.
--00000000000068d80f064f0d8be8--