From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 19 May 2026 19:06:15 -0700 Received: from mail-ot1-f55.google.com ([209.85.210.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 1wPWK6-0000Mh-VE for bitcoindev@gnusha.org; Tue, 19 May 2026 19:06:15 -0700 Received: by mail-ot1-f55.google.com with SMTP id 46e09a7af769-7dcc9e6b772sf13732270a34.0 for ; Tue, 19 May 2026 19:06:14 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1779242769; cv=pass; d=google.com; s=arc-20240605; b=QU7KZiMAf1XwnUApD3Ip1B2vbQNumFtXYvjgx2Ik8X9eQRzu6+GsDN4uX3RKJH6Q31 98sRNe2IPACikWon4Xg+gzK4ltZL5p4NCgPsVk92IEZ15nT3ivp6k5i0thBTLA4+oh+S kGPknB0OLx04JpkTBbOAvxGuz1BBcer1lFHPghGtln0IOwtje9PFGvTpmCzOojOVyjdh OgCfPkcnJuk0EGRmyeKIQGKn9J7iQQL1m4mDMz3e/0+trqO1u+1uqJb8Df0Qe5GRJPLM Wa+DygUYfcH9g0SW82uGaqHcUgN3hi8cvjFvY8b1/QyFvTPiE1G6MwhGG/Upz10XQr6m rfxw== 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:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:sender :dkim-signature; bh=3Izn/EbIFhodR57u+HA4bmOFCk2kmLyHxKOZjbbJ9s0=; fh=3oNh1ISr3pkrYcEeKwZIH4JDIQHhobfCfLzVvE6suPE=; b=d1/MzusdxH4EXo9HDegMO+0UVrCX7pyjPlX/9qz9zAIWFwCjbelzRNztrTU1Saeqtn YHDxw8mVXs/1NQxhtkxx9NmzBZ+54K3n6EnpnC3hpc3Mx6tOZfZ5od6i3gQ18+VRev1h gxk3ZuWzKfa96fsJeMTecWWlVhyQaLu6ToDpmfZrNYVRQReeNujmH7atCWg205IFQhk6 +Hh4NvtftYKBvD3t7yvs4jTB+4LZEAFDlcBn8QjsNgDdLuaI+3WNv43038nLPV1bl6wK 7E0V5b/QBCJJZK65rgo0l+03jmKeAGuK2QYJ5BcoTMrlAMQerCj3biwrpdjweZysAs9+ 7EjQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@wuille.net header.s=protonmail header.b=blV7ou2F; spf=pass (google.com: domain of bitcoin-dev@wuille.net designates 185.70.43.17 as permitted sender) smtp.mailfrom=bitcoin-dev@wuille.net; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=wuille.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1779242769; x=1779847569; 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:mime-version:feedback-id:references:in-reply-to :message-id:subject:cc:from:to:date:sender:from:to:cc:subject:date :message-id:reply-to; bh=3Izn/EbIFhodR57u+HA4bmOFCk2kmLyHxKOZjbbJ9s0=; b=D5v8s78Ku/I2cG95bY9cr3+OvOfoJ85T04QXSvsQu7r4qyYdL/6D3HjC4LGZ8xDo6l IJ8h3z/UIpSxScxf0Lj2k/ZSA/fkzv2A4BUwXt1PTRRp6jc0t26OurII8BCY0L1WJVUD 0/nhqsmC98/AvLg2pLiSNari+jL9lYXwWm4iddRFaC4UvLox/FKacx0BvAXKSuszDvB4 2NHr/BtKHvAniaDqLrYQ+UVndKoBdqEQdPc4mbKGJt1ZOIs+eANEnXx5+s/pQRh081ne Bztr8Ged1WIX1hXVH3Id1eECAvTE0nYP1NTDRozNO1m2Z9N2q9LsiNMabzoDAb9Xi9e6 uW7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779242769; x=1779847569; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence: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 :sender:from:to:cc:subject:date:message-id:reply-to; bh=3Izn/EbIFhodR57u+HA4bmOFCk2kmLyHxKOZjbbJ9s0=; b=EY+xJe3e3c32ox3edDm928veggQwba4WCzk8Qy7mloHPBBSSS0lWt7yXNPLOMoFyQM Wa52uB8QeDnq/YprW/8hCHRuLosKlbanWllAEo8LZLezK1Ou+mKoFdEYfvVGJktDJVt0 Vo/ZxVDZ/GTfVesl6FTc0yh3bg4aVudY3g1aGbAy4QfOX/CLlQaORhnIptKbf2KbGauf jSphgoCkQ5BmsHQts+ylOHqV/l3nvOuI2L3Y3NZSbR8KCixD0Chvo+Yw8blLAbpH1S7c zxx2sbArzD3kbfI3/vgQtQAaFzLaWYFA/HyEvhE4NKGMS1IFHKL6nGT3pLOLM1NbSdwu XrWw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AFNElJ8c4BMDmaK998Yf7f7NWHNYpN1IVkhfSrQSrGqGuMImTNcyF3MYkzv0HViSv9MhNhZxQe4cTxxPApRP@gnusha.org X-Gm-Message-State: AOJu0YxfuLHbtbopRofk/1mDJdP8Vqd6loG1LF+0RhWmCfq3GkweFxrT mB4Lqa2nxegvedmqLR5WCcjC/nyWGKLIEDPV1w8JOnqsVPN6/0tH/8ns X-Received: by 2002:a05:6820:615:b0:694:843a:5547 with SMTP id 006d021491bc7-69c77a88e6cmr11080994eaf.16.1779242768520; Tue, 19 May 2026 19:06:08 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMMI+p4bQVVHx9UKMHF4Jh0Unhldvqd4XS9wRwiTSLKF4w==" Received: by 2002:a05:6871:e499:b0:42c:d01:d9e1 with SMTP id 586e51a60fabf-439cc810edcls2634148fac.0.-pod-prod-00-us-canary; Tue, 19 May 2026 19:06:04 -0700 (PDT) X-Received: by 2002:a05:6808:3992:b0:467:2f58:dff3 with SMTP id 5614622812f47-482e4699588mr13304766b6e.18.1779242764237; Tue, 19 May 2026 19:06:04 -0700 (PDT) Received: by 2002:a05:600c:1688:b0:488:965a:b7a8 with SMTP id 5b1f17b1804b1-48fc95da45ams5e9; Tue, 19 May 2026 12:31:59 -0700 (PDT) X-Received: by 2002:a05:600c:528c:b0:48f:d612:3c6e with SMTP id 5b1f17b1804b1-48fe60de745mr318982975e9.2.1779219118073; Tue, 19 May 2026 12:31:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1779219118; cv=none; d=google.com; s=arc-20240605; b=IilXLcZdQ5/aKTiyMGttdc75RXLDOXt7xfiE8T8+XpABPtp3iQzsgCu4TNSgeYMuiy Z3tcQ30OwCjhQFs3neIQNDENXzC0M3I892QBCc+Bs0V18KV0W2C+sA66tajpPGborF4w S46FZoot4OmXw+RyhI80V0byrR70O2+8LtQrVCRwEYPbdyMheHhSusmKvpCagcyXnAT3 WtEile+E43mKZOnFxdtA/YwQefHC+YmMMgD3K2QmJeyYk9gvBmNG3ZMaKNtAocflHb81 LRiceTneyjYvDP2Tw+b9B/la+vsN8/5LLXcupTsqahvXY0vpR241YD4Mv2VQ7YSzNjiG 7Qdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=7AoxjlLAF/C/sKtSXgK/VNkjDS+mJYfcnFrLXv836s8=; fh=aLCQdAC+qOlZswv4b2ODrS4x1FFLLH6Bw8xxp+OpW+E=; b=S/cyPSk4HmXoGnBnO0J2GV/iExSGmRaOw9bTVF+st3ectlvZgs6AZYeEBTXbe7nUBz jnIW99A7Jfr1mxxHTE0OnR0Mn2kJnfWOJuOvuQV/xHWLHpaHb6+ii84nAQw/atL6hLgL T8iwsdOx3dfO5MVzJ9TQhZhvb7vKghhw5sns89JQgYxZCMqYpXC2aPdv98nFRM1Dwl6c cFw0V0PSdSZDj7BJFXPiZBsF6QB+GC7tady7zb3dJ4ONBwyx0bWATmlaDW+c6Lm1ksxQ N7l9SPJ03YJzHbZ+GWRkW7JmUV2inTktC88bZXRdksR9RARZm/83JAjR7ZsCOvIc4HrJ 6A8A==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@wuille.net header.s=protonmail header.b=blV7ou2F; spf=pass (google.com: domain of bitcoin-dev@wuille.net designates 185.70.43.17 as permitted sender) smtp.mailfrom=bitcoin-dev@wuille.net; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=wuille.net Received: from mail-4317.protonmail.ch (mail-4317.protonmail.ch. [185.70.43.17]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-48ff2cb86e7si1348025e9.0.2026.05.19.12.31.57 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 May 2026 12:31:57 -0700 (PDT) Received-SPF: pass (google.com: domain of bitcoin-dev@wuille.net designates 185.70.43.17 as permitted sender) client-ip=185.70.43.17; Date: Tue, 19 May 2026 19:31:53 +0000 To: Jason Resch From: Pieter Wuille Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] A "Quantum-Agile" Bitcoin address proposal Message-ID: In-Reply-To: <8d22c782-6da1-46f3-aa12-f686d5e1746dn@googlegroups.com> References: <8d22c782-6da1-46f3-aa12-f686d5e1746dn@googlegroups.com> Feedback-ID: 19463299:user:proton X-Pm-Message-ID: 0434332c93d8dc6c22824010b19799e4ad434e5d MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_4dXNGnM8sqYGoiNDhBeRo0NN8PdWQiB2xMHPGRlt7U" X-Original-Sender: bitcoin-dev@wuille.net X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@wuille.net header.s=protonmail header.b=blV7ou2F; spf=pass (google.com: domain of bitcoin-dev@wuille.net designates 185.70.43.17 as permitted sender) smtp.mailfrom=bitcoin-dev@wuille.net; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=wuille.net 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.7 (/) --b1=_4dXNGnM8sqYGoiNDhBeRo0NN8PdWQiB2xMHPGRlt7U Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jason, I think that in technical terms, this is how many people already think abou= t PQC adoption. Most proposals (including P2MR and P2TRv2) are built on the= script merkle tree construction introduced in Taproot. By having multiple = leaves in the tree, with distinct PQC (or EC) keys/opcodes in each, it is p= ossible to have multiple schemes in parallel. However, I would not consider this "agility", but rather a necessary evil a= s the significant trade-offs in PQC schemes today (large signatures, high v= alidation costs, lack of features like homomorphic derivation, low confiden= ce, or combinations thereof) make it so that there is unlikely to be a sing= le scheme that covers all needs. In fact, I would go as far as claiming that to some extent, the more scheme= s are available, the less cryptographically agile Bitcoin becomes, assuming= those schemes are actually adopted. This is because unlike in TLS/SSH/IPSe= c, one does not solely care about protecting their own connections/coins, b= ut also other users' coins: if you believe many coins are held in insecure = output types, you're likely worried about the effect on the currency's valu= e in case a large-scale theft happens, even if your own coins are secure. O= f course nobody can promise anything about Bitcoin's exchange value, ever, = but it is shortsighted to ignore this aspect, and makes it effectively a tr= agedy of a commons: everyone has an incentive to make everyone's coins secu= re. Bitcoin is, in my view, a consensus of rules, but also a consensus on what = cryptography is considered secure. Giving users the option of more schemes = means extending that consensus to needing all=E2=80=8B of them to be secure= . That does not mean we cannot add schemes of course; obviously any actual = PQC migration will boil down to adding new output types and having users mi= grate to them. But I think it is misleading to consider such flexibility a = positive property. More detailed comments inline below. On Tuesday, May 19th, 2026 at 2:43 PM, Jason Resch w= rote: > and let end-users decide which one algorithm or combination of algorithms= , best fits with their use-case, security requirements, and trust for diffe= rent algorithms. I agree that's what may well happen, but for different reasons. If there so= mehow was one PQC scheme that everyone considered secure and supported all = the features we needed, I am staunchly of the opinion we should be adding t= hat and nothing else. Such a scheme is unlikely to exist, so we may be forc= ed - possibly over time - to adopt multiple schemes for different use cases= . Still, the choice between them will follow guidelines, or practically spe= aking, wallet/provider implementation, not end user choice. > In short: > > - A wallet chooses one or more public keys from one or more approved sign= ature algorithms. > - This ordered public-key bundle is serialized canonically and hashed to = form the address. > - Senders do not need to know which algorithm or algorithms are behind th= e address. > - At spend time, the spender reveals the public-key bundle and provides o= ne valid signature for each key in the bundle. This is effectively what the BIP341 script tree already gives you, if multi= ple PQC opcodes were added. > - Users who want higher assurance can use heterogeneous algorithm familie= s, while users with lower-value or high-frequency wallets can choose cheape= r single-algorithm profiles. While that is what may practically happen, I don't consider this a good thi= ng, because of the tragedy of the commons here. Users who own small amounts= that move frequently would likely rather see others adopt PQC rather than = themselves. > - It enables rapid migration to other algorithms, should any future crypt= ographic break or even suspicious of possible future breaks, occur in the f= uture, without having to wait for a new consensus for a change to the Bitco= in software and protocol. I do not consider the ability for individual users to move their coins over= to something else "migration", unless there is a reasonable expectation th= at ~everyone moves away. Due to the need for consensus on which schemes are= secure, I'd call Bitcoin pretty much the least cryptographically agile sys= tem imaginable. > - End users can choose security levels that correspond to their security = needs and spending habits. Have a cold-wallet securing millions of bitcoin = which you spend from once per decade? Use several PSQ algorithm families wi= th large key sizes, and pay higher transaction fees for those rare occasion= s you move funds. Have a small spending wallet you use to make online purch= ases? Use the smallest key size possible to save on transaction fees. Sure, and this is especially relevant with the recent work on stateful and = stateless hash-based signature schemes, which have significant trade-offs f= or cost and security that depend on the use case. Still, like above, I don'= t consider that an inherently positive property, but an unfortunate necessi= ty. -- Pieter --=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/= pG8q9uABWbOoiN1qZI3TWf-oloP08k3UOpy0cjHZGoFq0P_xVufCwvtKtdFNL3SkC8P4gAfLtLM= 4v_89TfbUEVXlU9a6OYo9f02jKRetxRs%3D%40wuille.net. --b1=_4dXNGnM8sqYGoiNDhBeRo0NN8PdWQiB2xMHPGRlt7U Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jason,

I think th= at in technical terms, this is how many people already think about PQC adop= tion. Most proposals (including P2MR and P2TRv2) are built on the script me= rkle tree construction introduced in Taproot. By having multiple leaves in = the tree, with distinct PQC (or EC) keys/opcodes in each, it is possible to= have multiple schemes in parallel.

How= ever, I would not consider this "agility", but rather a necessary evil as t= he significant trade-offs in PQC schemes today (large signatures, high vali= dation costs, lack of features like homomorphic derivation, low confidence,= or combinations thereof) make it so that there is unlikely to be a single = scheme that covers all needs.

In fact, = I would go as far as claiming that to some extent, the more schemes are ava= ilable, the less cryptographically agile Bitcoin becomes, assuming those sc= hemes are actually adopted. This is because unlike in TLS/SSH/IPSec, one do= es not solely care about protecting their own connections/coins, but also o= ther users' coins: if you believe many coins are held in insecure output ty= pes, you're likely worried about the effect on the currency's value in case= a large-scale theft happens, even if your own coins are secure. Of course = nobody can promise anything about Bitcoin's exchange value, ever, but it is= shortsighted to ignore this aspect, and makes it effectively a tragedy of = a commons: everyone has an incentive to make everyone's coins secure.
Bitcoin is, in my view, a consensus of rules, but also a consensus on wha= t cryptography is considered secure. Giving users the option of more scheme= s means extending that consensus to needing all=E2=80=8B of them to = be secure. That does not mean we cannot add schemes of course; obviously an= y actual PQC migration will boil down to adding new output types and having= users migrate to them. But I think it is misleading to consider such flexi= bility a positive property.

More detailed comments inline below.

On Tuesday, May 19th, = 2026 at 2:43 PM, Jason Resch <jasonresch@gmail.com> wrote:
and let e= nd-users decide which one algorithm or combination of algorithms, best fits= with their use-case, security requirements, and trust for different algori= thms.

I agree that's what may well ha= ppen, but for different reasons. If there somehow was one PQC scheme that e= veryone considered secure and supported all the features we needed, I am st= aunchly of the opinion we should be adding that and nothing else. Such a sc= heme is unlikely to exist, so we may be forced - possibly over time - to ad= opt multiple schemes for different use cases. Still, the choice between the= m will follow guidelines, or practically speaking, wallet/provider implemen= tation, not end user choice.


In short:
  • = A wallet chooses one or more public keys from one or more approved signatur= e algorithms.
  • This ordered public-key bundle is serialized canonica= lly and hashed to form the address.
  • Senders do not need to know whi= ch algorithm or algorithms are behind the address.
  • At spend time, t= he spender reveals the public-key bundle and provides one valid signature f= or each key in the bundle.

= This is effectively what the BIP341 script tree already gives you, if multi= ple PQC opcodes were added.

  • Users who want higher assurance can = use heterogeneous algorithm families, while users with lower-value or high-= frequency wallets can choose cheaper single-algorithm profiles.

While that is what may practically hap= pen, I don't consider this a good thing, because of the tragedy of the comm= ons here. Users who own small amounts that move frequently would likely rat= her see others adopt PQC rather than themselves.

  1. It enables rapid migration to other algor= ithms, should any future cryptographic break or even suspicious of possible= future breaks, occur in the future, without having to wait for a new conse= nsus for a change to the Bitcoin software and protocol.

I do not consider the ability for individual u= sers to move their coins over to something else "migration", unless there i= s a reasonable expectation that ~everyone moves away. Due to the need for c= onsensus on which schemes are secure, I'd call Bitcoin pretty much the leas= t cryptographically agile system imaginable.

  1. End users can choose security levels that cor= respond to their security needs and spending habits. Have a cold-wallet sec= uring millions of bitcoin which you spend from once per decade? Use several= PSQ algorithm families with large key sizes, and pay higher transaction fe= es for those rare occasions you move funds. Have a small spending wallet yo= u use to make online purchases? Use the smallest key size possible to save = on transaction fees.

Sure, and this is= especially relevant with the recent work on stateful and stateless hash-ba= sed signature schemes, which have significant trade-offs for cost and secur= ity that depend on the use case. Still, like above, I don't consider that a= n inherently positive property, but an unfortunate necessity.

--&nbs= p;
Pieter

--
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/pG8q9= uABWbOoiN1qZI3TWf-oloP08k3UOpy0cjHZGoFq0P_xVufCwvtKtdFNL3SkC8P4gAfLtLM4v_89= TfbUEVXlU9a6OYo9f02jKRetxRs%3D%40wuille.net.
--b1=_4dXNGnM8sqYGoiNDhBeRo0NN8PdWQiB2xMHPGRlt7U--