From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 09 Apr 2026 17:34:07 -0700 Received: from mail-oa1-f55.google.com ([209.85.160.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wAzp1-0005Lx-97 for bitcoindev@gnusha.org; Thu, 09 Apr 2026 17:34:07 -0700 Received: by mail-oa1-f55.google.com with SMTP id 586e51a60fabf-42343e87c3asf1572000fac.0 for ; Thu, 09 Apr 2026 17:34:06 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1775781241; cv=pass; d=google.com; s=arc-20240605; b=QbHR9De7PiUfCyvUnFVLMIKi532//b1zFc5bZh5/Slzb10TYKSbQE8FcVjC6eBPkFe JuEnDvxJtG8PV5dOvibd8tLpMUHWoaJpv5OayL0Ui8vi4KQ25pxI4PkjHZbA4ecdAg5Y nwy8Y/fmIueoQMXze5fuxzf2sdcdPQYsAhJh5C9I8VmK02t5j3WBml0AC0M3kuH+Qv5/ veglseMUsBhzmcm0A4YMUKGoYL5mk0la8wlkYSFSqGVDi3baIVsesISBjZHGNFTtPczW 1DXJ2W65OuHU8TEr4YR/1muUGQcBRUCy0VV7tMcFvwMoDRFQBKNLCXIUJV/1uqblvI4E YCuA== 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:in-reply-to:from:content-language :references:to:subject:mime-version:date:message-id:sender :dkim-signature; bh=5PS775Ncgh3mEiVSj6gy0WKfwdcUmSycpRlrskPBzxw=; fh=f6ksWRhIMeK+ZhYKtXmqXQUquoMIdMG3rz0YzdJ9bTk=; b=A1Y2bWM0C4gXFVS2z65vwBGpT3r+FPrvCZZeca8j7kBneO6y9hjsZ1pS5aqmCcRVny F3Y5tj1TA/6joX0ggMXkS3i2bBmyALQQJtmK/3YklmC3tkPBEBmTKihEvehN4kEYc+Rq LJUEaBwMdfaVjjP5u6JJguqYV8ENT3tPYsIRelPNdcNf9BezI9zdBN7nFLhcbh4408Cv ridZhmF1REbHx4lPW/NBkZOdFt5KsIBOjGiBqq06OUU8OV0U0/KOlIexRc3NpxLpQjzx Qtqg/zIaUuZg3efwliPU61xirCcvjLJkXj9Jkd+DL4nxoAWubxaZqPoahEwCa1xQEbb1 QIbA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1775773262 header.b=HATINM17; dkim=pass header.i=@clients.mail.as397444.net header.s=1775773264 header.b=UztjHxHY; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1775781241; x=1776386041; 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:in-reply-to:from:content-language:references:to :subject:mime-version:date:message-id:sender:from:to:cc:subject:date :message-id:reply-to; bh=5PS775Ncgh3mEiVSj6gy0WKfwdcUmSycpRlrskPBzxw=; b=NIZaIqZoc4LnkLszGYQlY7y55ird3hfABOzZg1DxCkDvJvPPp23kFo/4aLAAfan3WL gObkKKijUEfnCwO8g24UWjVJaV+gPG2VWiRtcvdi+1+9Cp4FGu13kqwPf1ObjwjOQ3hB GNpGGykqciLCozS8h5wmOuZx2x+2WrykeYgV0Eq7gFecHribrA/c9VWquq/aRRTz3ifj fbX/uivMRV70hOCvJbmaY2zdYPR74bt/2mLPPlDVdrAEoMGHhOJ0il06j/iN+6mwv+T7 nwmmO0c3j2U4/ZRbz+rF5Oa7UrBom8gwnNZAQ9p5yKDfZzXj8Mkx8K9pgAxZ7oAhH9Tl fIpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775781241; x=1776386041; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:in-reply-to:from:content-language:references:to :subject:mime-version:date:message-id:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=5PS775Ncgh3mEiVSj6gy0WKfwdcUmSycpRlrskPBzxw=; b=l5sWETx/ADnIDV+VAmpe/x5TY6YyVApxUG4Lofnt4nFUOqIsqnyKu7TQL2/wwkXJ1O 2us0cUcxYAz6+Mv3vxrhXWZhRBF6Po2n/V45AqacW2sgiIPmUfDL5ZbPUUhFRVQicSt+ 3d3FaN7+XRxFyYB4i/RR6a3IShaXWEx/rEYUSiS/KvubXyRPqMf+FQVj7jUZaf37tpI/ LRNv9DsawE0TmwV+VavMdPQx4V02bLcmoCu7Ni0g0wbUksuGodQf76jeYSkbg5+0TNm6 Ap2MgYjo9ilDpXKu/qwO826srGUZ0wKJHNTKxwmIghEuAwk1rPYcSahcqX9k04qOOsn6 stGQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCXpZ0BSrGw6+UqFhlDVRzTkog/8YH35oOBVenwP9uEDTP6rU6RFLbNXsvCyZ+zWfrkgs+d2JArbUcw5@gnusha.org X-Gm-Message-State: AOJu0Ywkr8G6WXPkewEOYd8cpyF9UZ1KCa2330Qt5im8W/r+ZnPlshUH V35ZG/9noxeR0nzyut1b3gaqev8rMdN7HHp46Nsi5FeeDbgwOS75u/Ws X-Received: by 2002:a05:6820:1b18:b0:68b:cadc:4340 with SMTP id 006d021491bc7-68be604a404mr615656eaf.18.1775781240645; Thu, 09 Apr 2026 17:34:00 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiJfA6OZv3hPY09/P+VrkmUCuPylh8WzeLE5+fcOpPbGOw==" Received: by 2002:a05:6820:f00e:b0:67d:1242:e69b with SMTP id 006d021491bc7-68bc133f12bls177936eaf.1.-pod-prod-06-us; Thu, 09 Apr 2026 17:33:55 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCUsCqzEJyzzh+9cFEuT5MgUmDPoeuDvn1CGrPYQSAyVw8DKWgDYbTb8kD/aY/PvQMSwpefcXXSKeuxL@googlegroups.com X-Received: by 2002:a05:6808:181d:b0:45c:925b:5848 with SMTP id 5614622812f47-4789f507c13mr652763b6e.45.1775781235738; Thu, 09 Apr 2026 17:33:55 -0700 (PDT) Received: by 2002:a05:620a:7293:b0:8b2:e5d4:9264 with SMTP id af79cd13be357-8db3d124955ms85a; Thu, 9 Apr 2026 15:46:40 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCXTfSdeJKWVWtZ5W2GwtUCzcQ3/N5pVyCzZtF+yT7NmqPtwmNB2PXxGgUdJR407eKS09us4wl0IVVEF@googlegroups.com X-Received: by 2002:a05:622a:4d93:b0:50d:8408:c5e5 with SMTP id d75a77b69052e-50dd5d66bf2mr15915761cf.64.1775774799520; Thu, 09 Apr 2026 15:46:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1775774799; cv=none; d=google.com; s=arc-20240605; b=KXkNUQn3mHacyLxeKl54Bc6IqTjEgdkg9RsEC8Zo1EeKXwRURDMSFagWii25Fr7u61 MCNXMS3AlstkHP36JFGR9uIVyK1gWkym7EOlcxB4MaBKJHVCPIaFep72hnBoFrDtBRke 7nBfO7mhhtCshdCY1HDnIdccG1csDU0y/+kmnvmAW5xEznp7vHEba4nv1ps+KS7fpqqW /sRAntfF66bGJ3k0kdxtGmnkJmd7kZEMh1O3jffhe9L0sE02pGbTAl3jTUNoIrdnv2Rh Mt7wgXkc8zzAcatlVBvdjBczcGbVUiTpzsjTHEJH+J4QatyYXpoD32BDiQwY5BXzEA/R McQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:mime-version:date:message-id:dkim-signature :dkim-signature; bh=rc/oWDU+9foTW08806sj2t5dtmCLAYdS3amTgv+5x3k=; fh=02nJZxx48b/TyKrcvewNiN7FJtTrEjLEvj+vPN5r4s8=; b=Qdzh5DB37sFXPaX2PSVCgG3v5NCNdXvWKoOnMg4AvS+wB10PUNPm1xmq+WOng4mtVE Y15EQ9ynM0vNN36PQ2N7IYAdeTNVSlkcRmNWqeO+Dt8GVfXUZxEEo6rd+Gsyf13H1n8x cXiF/Qycn+dAiQKfSP+oHaCKhTSDtFZqlin0RIL28lJknIADHzZ2tHrhthYES6E7sCrV xVJRc0GIsvQO2h95Nd0FYJucEIMWTCHuUnBthe4MB6eD0FjH+gFazdstDTosYTtkOjQp 5afKdFBC+NXPpJOEoos+ge73nmJjeu518vHBEashQu3YkGN+v0tiY8dnDSzwJ1ASSQO+ lzAg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1775773262 header.b=HATINM17; dkim=pass header.i=@clients.mail.as397444.net header.s=1775773264 header.b=UztjHxHY; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com Received: from mail.as397444.net (mail.as397444.net. [69.59.18.99]) by gmr-mx.google.com with ESMTPS id d75a77b69052e-50dd56539acsi299561cf.5.2026.04.09.15.46.39 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Apr 2026 15:46:39 -0700 (PDT) Received-SPF: pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.99 as permitted sender) client-ip=69.59.18.99; X-DKIM-Note: Keys used to sign are likely public at X-DKIM-Note: https://as397444.net/dkim/mattcorallo.com and X-DKIM-Note: https://as397444.net/dkim/clients.mail.as397444.net X-DKIM-Note: For more info, see https://as397444.net/dkim/ Received: by mail.as397444.net with esmtpsa (TLS1.3) (Exim) (envelope-from ) id 1wAy8z-00000004vQb-0tbY; Thu, 09 Apr 2026 22:46:37 +0000 Message-ID: Date: Thu, 9 Apr 2026 18:46:35 -0400 MIME-Version: 1.0 Subject: Re: [bitcoindev] In defense of a PQ output type To: Antoine Poinsot , Bitcoin Development Mailing List References: <0vqF88LoOnY4GiUB4vf-MdeZpTAtR70tokS3cLwt2DX0e6_fD1X_wyhPwWEdIdm6R88AULObIU08CWsb5QfeoaM5c4yXPqN5wHyCrqMCtfQ=@protonmail.com> Content-Language: en-US From: Matt Corallo In-Reply-To: <0vqF88LoOnY4GiUB4vf-MdeZpTAtR70tokS3cLwt2DX0e6_fD1X_wyhPwWEdIdm6R88AULObIU08CWsb5QfeoaM5c4yXPqN5wHyCrqMCtfQ=@protonmail.com> Content-Type: text/plain; charset="UTF-8"; format=flowed X-Original-Sender: lf-lists@mattcorallo.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1775773262 header.b=HATINM17; dkim=pass header.i=@clients.mail.as397444.net header.s=1775773264 header.b=UztjHxHY; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.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.8 (/) On 4/9/26 2:58 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. You've missed the much-more-important thing that cannot be extricated from disabling insecure spend paths - the ability to recover from a seedphrase. In any world where a CRQC exists, whether it is next year or a century from now, there will be a million or two bitcoin in lost-key-wallets and a nontrivial amount in wallets people haven't touched in ten years but still have keys for. Given a goal of any migration strategy should be to enable the absolute maximum number of coins to be retained by their owners (I think this is basically the *only* goal?), enabling seedphrase proof recovery is pretty critical. Sadly the only way that can be done is through disabling insecure spend proofs. But you've also confused unrelated concerns here - whether a hash-based signature is added as a tapscript opcode or not is not strictly tied to whether a new output type is created. If BIP 360 is the way bitcoin goes, it *still* needs a new hash-based opcode in tapscript. Maybe more interestingly, a new taproot "version" could be added which has identical semantics to today's taproot but signals through an alternative version number (or maybe there's a cleverer way to encode a bit somewhere that we should prefer) that a PQC pubkey exist in a taproot leaf somewhere so the insecure spend path should be disabled. > 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. Adding a PQ output type which no one will use (eg one where use of the hash-based signature is mandatory, which drives fees up hugely and has all the drawbacks you mention) is not a risk mitigation strategy - it does not materially allow for any migration and doesn't accomplish much of anything. But as mentioned above I do not see why any addition of hash based signatures to tapscript should require any kind of community consensus on future disablement of insecure spend paths - not only is it a likely prerequisite for an alternative output type, but its also (obviously?) not possible to have any kind of "consensus" on what the future bitcoin community will do. Thus it would be rather impossible to do *anything* if that were a requirement. > 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/cba894e1-f830-4ad5-9498-09f04faaadf7%40mattcorallo.com.