From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 19 May 2026 11:43:07 -0700 Received: from mail-oa1-f59.google.com ([209.85.160.59]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wPPPH-0004rk-5u for bitcoindev@gnusha.org; Tue, 19 May 2026 11:43:07 -0700 Received: by mail-oa1-f59.google.com with SMTP id 586e51a60fabf-43a281ca836sf9530079fac.1 for ; Tue, 19 May 2026 11:43:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1779216181; x=1779820981; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:sender:from:to:cc:subject:date :message-id:reply-to; bh=YV/fkekAB7ge9YCQUZT2/eC22u+LjYiP2m6aNdcbyus=; b=bkbm7rx9wv+GGrEF85xl0GDybjYQZ2RON8tmX5V3LxQ0rFB4mQoJcQoJBwra3/2PEn IbeyWMHbC7QhUWfJr/eUG8aS7OruYCF97oAI+/cBIXCI2LRMLXE3KQUX5CT9ZqRHFHOF KAa7b8AiWI9hS/MmVogXgQKsEruwhP95x8zzJ25qKU6Ieywa0oozaSRcararjvXr9pB8 JCLkXRl8ATFqXas7kM/7YoMHfdd6SFv4TiEwUtkdnXehv2YRMRirZ9FE5YFqcwy6VFqv QVJYlqFGWSTVWIGpOvoB9ttC4LIBlnos7G/ygKqwE19M/ReHUKbfCouGCF6m2kBprf2O x+xQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779216181; x=1779820981; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:from:to:cc:subject:date:message-id :reply-to; bh=YV/fkekAB7ge9YCQUZT2/eC22u+LjYiP2m6aNdcbyus=; b=Gy4E87Y7BFyTJEwDUTLmOmTZAkwvcc7+gNWS4nPkZJVR8JO/A+xh6s9DoqiHefnLQc 8bqhIVvBVhtHDBvoxymiY4STLQiPBQn0pRiCyCkkMfQJtLIE6vRElMw0zpckGgXyYrqV j3lwQ+v3TM8rruGbePGC/XL/krUe7Ih2vxFgDLUk15TljOvfG2pw3vYRAw4eoQWqgA56 RDci63ePM34OO274NlBXcnciJTEQLkSvJgEzJfRvOBH8AYHgg4kv9puKFiDS+3uNAHoG nMjKhTBcG1DFOcuziJuGyYuECPfh8+wENoqSRA6arcV0+7v3P/uNxvYjRamlj0BoI/ff 0vjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779216181; x=1779820981; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=YV/fkekAB7ge9YCQUZT2/eC22u+LjYiP2m6aNdcbyus=; b=bfmO7sOXEtKEBMAOhoYidU3T5GGXAjD+0bEiESpAi+zChMkd6dlHQM8lqtIg8bll1J ZNNbRDhRc67rOtjtlASBKhQxSOYWnUUzHgEcei+MibOzOr5AYoFdMP64ZXper6vMGO06 ErzwFQIxnl5vVWedjqjOf9VtSeMqsoH/FBNbZY34HWbDQE33/T4tJC4IKQtAorFh0jZa i4sBXXeUeK1Ih+RIoBfV/cPcpnKOY1vKY12IZQ6MHBwWPP1j2rtU72Dh1grukSr+LjdQ dpUqVKPAvZEw2ZCcURveebXOxMAHREkavEPQyNeojYWwPU6ONQkDDVvTO+vlt4N7HSxE Djeg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ+CAogp2o2fnbbSIMcvsi0Lb9eTdSY+Hawo9Apm/3PjQORWpqMRS08GN7X1DEH1/tm/kdtrGjRCVxtX@gnusha.org X-Gm-Message-State: AOJu0Yyvj/XtGwz/bQSxXHorgLvOsAw4sFeXxSScFj2nHCDPTVWE1ONv wwU3/53fHKMxLaTlcXng6CR82NdQOF+ZRVL/bfSpCdMnEppXr9YWddLz X-Received: by 2002:a05:6870:239e:b0:439:cbc3:c075 with SMTP id 586e51a60fabf-43a2db834e6mr14112310fac.7.1779216180641; Tue, 19 May 2026 11:43:00 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMNerZ5hTDcA2NC3BvonXqYX6w8t1TdGLZs08BFeH+ae2w==" Received: by 2002:a05:6870:1156:b0:3c9:732d:60f2 with SMTP id 586e51a60fabf-43a01e916bcls2263659fac.1.-pod-prod-02-us; Tue, 19 May 2026 11:42:55 -0700 (PDT) X-Received: by 2002:a05:6808:c1e6:b0:479:fca7:4647 with SMTP id 5614622812f47-482e55e5cffmr13262427b6e.2.1779216175064; Tue, 19 May 2026 11:42:55 -0700 (PDT) Received: by 2002:a05:690c:b03:b0:7d0:63a3:69e7 with SMTP id 00721157ae682-7d063a37787ms7b3; Tue, 19 May 2026 11:11:15 -0700 (PDT) X-Received: by 2002:a05:690c:dd3:b0:7b8:926e:3f0d with SMTP id 00721157ae682-7c95c6f6efbmr218894467b3.26.1779214275147; Tue, 19 May 2026 11:11:15 -0700 (PDT) Date: Tue, 19 May 2026 11:11:14 -0700 (PDT) From: Jason Resch To: Bitcoin Development Mailing List Message-Id: <8d22c782-6da1-46f3-aa12-f686d5e1746dn@googlegroups.com> Subject: [bitcoindev] A "Quantum-Agile" Bitcoin address proposal MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1128778_926447114.1779214274607" X-Original-Sender: jasonresch@gmail.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 (/) ------=_Part_1128778_926447114.1779214274607 Content-Type: multipart/alternative; boundary="----=_Part_1128779_160557800.1779214274607" ------=_Part_1128779_160557800.1779214274607 Content-Type: text/plain; charset="UTF-8" Dear Bitcoin Developers, I've been thinking about the threat of quantum computers to ECDSA, and I had an idea that I consider to be valuable and worth sharing with the broader community. The essential idea is that rather than attempt to choose any one post-quantum-secure algorithm as a replacement, instead, bitcoin ought to support a set of various algorithms, and let end-users decide which one algorithm or combination of algorithms, best fits with their use-case, security requirements, and trust for different algorithms. In short: - A wallet chooses one or more public keys from one or more approved signature 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 the address. - At spend time, the spender reveals the public-key bundle and provides one valid signature for each key in the bundle. - 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. This agile approach, inspired by TLS, SSH, and IPSec (all of which support multiple suites of different algorithms) has many advantages: 1. It defers the decision of which algorithm to use and trust to the future, when there will be more information available. Bitcoin developers can't predict what future algorithm breaks might happen, and enabling users to decide absolves Bitcoin developers of having to try to predict the future. 2. It enables rapid migration to other algorithms, should any future cryptographic break or even suspicious of possible future breaks, occur in the future, without having to wait for a new consensus for a change to the Bitcoin software and protocol. 3. 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 with large key sizes, and pay higher transaction fees for those rare occasions you move funds. Have a small spending wallet you use to make online purchases? Use the smallest key size possible to save on transaction fees. I have put together a white paper that offers some further detail on how this could work: https://zenodo.org/records/20292912 and welcome any comments/feedback. Jason -- 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/8d22c782-6da1-46f3-aa12-f686d5e1746dn%40googlegroups.com. ------=_Part_1128779_160557800.1779214274607 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Bitcoin Developers,

I've been thinking about the = threat of quantum computers to ECDSA, and I had an idea that I consider to = be valuable and worth sharing with the broader community.

<= /div>
The essential idea is that rather than attempt to choose any one = post-quantum-secure algorithm as a replacement, instead, bitcoin ought to s= upport a set of various algorithms, and let end-users decide which one algo= rithm or combination of algorithms, best fits with their use-case, security= requirements, and trust for different algorithms. 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 cano= nically and hashed to form the address.
  • Senders do not need to know= which algorithm or algorithms are behind the address.
  • At spend tim= e, the spender reveals the public-key bundle and provides one valid signatu= re for each key in the bundle.
  • 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.
This agile approach, inspired by TLS, SSH, and IPSec (all of which suppo= rt multiple suites of different algorithms) has many advantages:
  1. It defers the decision of which algorithm to use and trust to= the future, when there will be more information available. Bitcoin develop= ers can't predict what future algorithm breaks might happen, and enabling u= sers to decide absolves Bitcoin developers of having to try to predict the = future.
  2. It enables rapid migration to other algorithms, should any = future cryptographic break or even suspicious of possible future breaks, oc= cur in the future, without having to wait for a new consensus for a change = to the Bitcoin software and protocol.
  3. 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 dec= ade? Use several PSQ algorithm families with large key sizes, and pay highe= r transaction fees for those rare occasions you move funds. Have a small sp= ending wallet you use to make online purchases? Use the smallest key size p= ossible to save on transaction fees.

I= have put together a white paper that offers some further detail on how thi= s could work:=C2=A0https://zenodo.org/records/20292912 and welcome any comm= ents/feedback.

Jason

--
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/bitcoind= ev/8d22c782-6da1-46f3-aa12-f686d5e1746dn%40googlegroups.com.
------=_Part_1128779_160557800.1779214274607-- ------=_Part_1128778_926447114.1779214274607--