From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 19 May 2026 20:27:45 -0700 Received: from mail-oa1-f56.google.com ([209.85.160.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wPXay-0001BI-Af for bitcoindev@gnusha.org; Tue, 19 May 2026 20:27:45 -0700 Received: by mail-oa1-f56.google.com with SMTP id 586e51a60fabf-43a538158ccsf5170726fac.0 for ; Tue, 19 May 2026 20:27:43 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1779247658; cv=pass; d=google.com; s=arc-20240605; b=aAgIxKFCCwXaYxDyFCz3nbIs8JR64HJdwYTx7k7jIa4P+rO9GI2eSUbBLEY5lSzmJI nKPI7N8mQcN5biw/VYd6ML+KV37kWwc4YA9+37PDXkwe5Dp1kJadQfm/oFXi+rRpUHrs /+3DkjbkvvvrsBCzSJoV9vvjxiSX6ZEG4L1DY3+YpOjW6RI4amit+saHLU66LuYXxV0a JERx5en3ALAUoZVQBzMYdIQoFOaDxWNOS1WLy+HhRcd9LT4Mer7erKzxpTSxOZzh0A49 QeufnmGUfl5Ve3F1gogn88V+p7KKLhYUiD7fmnlnBStetvqNu2rab5zhuxEIibpXZCGl nKiQ== 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:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=Wvn7ztgXQwn9PJ/yxpU10rTD1EY4+/awhnTNK7nZTf0=; fh=3UWONg5K2Rtx3TROcNv/tGcBe8M7v6hCH+zeVmH6tQg=; b=B4yyckvD3+4lWyYB/hv1xKOqjdsXoheSBwPLPJU1IJHo9wB38pCtsSO0CsP+f8P9D4 EBfba3/rpPCQzmA180GfVPgm8Br4SeyIQ7VRGwPTO7h0AsccHUHIjArYZIwoapogTjyx 7kcmdEPmc7YO3D+2aV/p6Di/f1DrTMJGahi8jp8Fj3KwVUQ79GF2jdISJXEluq7IQuxJ APY0exHr5Q/gm+Ybvgec0Oo0gnBI5fhEty9MJ0x1FJxCsJBDsf+lWVk5FzVvxh7Za4bq XPSCf8oKx//YPECoHZocok0xMvD83NTzHk7O9OPFlAnU5nPjbJUU9Hkcpx7n7JwlLaO0 TLkQ==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=T36Ywdls; arc=pass (i=1); spf=pass (google.com: domain of jasonresch@gmail.com designates 2a00:1450:4864:20::531 as permitted sender) smtp.mailfrom=jasonresch@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=1779247658; x=1779852458; 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:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=Wvn7ztgXQwn9PJ/yxpU10rTD1EY4+/awhnTNK7nZTf0=; b=XfIaJ3CJfVaQdcaMonNtHTRT0qY29754kmwrSiuOhGWdLnIWIxtRyZov5hORi2sOEt idXWlm2wQV4xet3sP7GJYg0yWnvv6EufPLqrsMIsBn1wTH5Q7CdRoaTJaS0WebFqDnc9 AgMkqcbEdjyATLIPN8xXeE+f1EoAVZYq03jNfpolodo0MzBS5sClWKS2LFGKRY/8bppY v/Pf6mq6en/lkGxXvwCVn6/nu8+dJOEf3w5Z8g5jx0SEePHjI4wY77H/BtSph4WAFLuF kcb0+/BkyldDC8Qcbn9FZR8fGbAZSipijjkiidx+Yo2ckL1es0dJyuCcnlKUFLRKMz7b gWNQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779247658; x=1779852458; 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:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Wvn7ztgXQwn9PJ/yxpU10rTD1EY4+/awhnTNK7nZTf0=; b=JsBkx/8Yy37UO5vktXey6l0g+h461QTXAqUNXnW1Qy42muFGDNbI2QCUqZa7OpOfLu gBBCqYEhC842TFFIBY8pP5RM12cC8Zc/LOGEqcoODeSX5USy9apIfVh/LPefwtgcQesE FvDFG3yNUp5aX6t9iC8XzOoAGdEO4Nj82QdJak8N21y2wb+Sw0OFXYw0arUzXP7waf80 Ts4crPbTLQgma2jfyUM0uZWHSNDWPPqa0fwRWaN7oy1hk8EOjQIc8ONt7BvpyMVTk+WU bxXPZx7Y1VhmymW3oDjBIAhxJKzvkIxxFxi43grKICLK772TG5zMrjN5t+LvCPZLYc5L 4WRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779247658; x=1779852458; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender: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=Wvn7ztgXQwn9PJ/yxpU10rTD1EY4+/awhnTNK7nZTf0=; b=NN7PSQ6UFeYcGtp8mARmexJFgoP0qR5XYGJNjKG00/maz/8HmuMx3pnLfnAoLv43WD AiKOvwljaMlMNCcWGPdTYJAXX+AV2CCFSs1mE/s60ZzN0HlQIMtIEYxrd/XytFWXgvze SQxWJZFvfCct21y29E9A+YSipxSRoXvz1iOFWQK/lGiGApmR8zZcUm2spb4/6FRa4n9j um/4rHpdOk5t2rIwhmgmaZU5dOlcIFAchNSKPi8/XiKonGNg8Q1s2dYJ270Tl5SID013 3mKqci9Z0LhhNumDRIsO3LIzfyoS7ufK+7A7uwIzhv3a2FesYNZXFztQ+antUMy7WiK5 oQkA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AFNElJ+lBbrncLNvJRJBbDhPsvEhN6q096OsTu8/QZanukgbTZZ93V17EBb4HE7AnIW2WSH/imo0WRNtY4eb@gnusha.org X-Gm-Message-State: AOJu0Yzh1miFya9WVlQ/o4rQClyM1d+sh+3aC77SYZ50a9B4PrnZnP3/ HWbSwQqehpEgJIZJ3E3G/UYv3w7Co7buwsZyx/RgEsNl1xlJj87D/o7u X-Received: by 2002:a05:6870:1763:b0:41c:5589:ec48 with SMTP id 586e51a60fabf-43a2da1c6f8mr14577494fac.16.1779247657575; Tue, 19 May 2026 20:27:37 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMM5xkPb5gN91TzRbehHvW+n7XYC0Hwy++Tkxqidt1lWNg==" Received: by 2002:a05:6870:1406:b0:42c:176a:4367 with SMTP id 586e51a60fabf-43a01ebe5ffls3189109fac.1.-pod-prod-06-us; Tue, 19 May 2026 20:27:31 -0700 (PDT) X-Received: by 2002:a05:6808:c3ec:b0:47c:3f6f:db9a with SMTP id 5614622812f47-482e5612f1fmr14924192b6e.15.1779247650913; Tue, 19 May 2026 20:27:30 -0700 (PDT) Received: by 2002:a05:600c:2059:b0:488:963a:630a with SMTP id 5b1f17b1804b1-48fc95d1683ms5e9; Tue, 19 May 2026 20:10:36 -0700 (PDT) X-Received: by 2002:a05:6000:609:b0:455:51cf:9f92 with SMTP id ffacd0b85a97d-45e5b895767mr36761728f8f.18.1779246635414; Tue, 19 May 2026 20:10:35 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1779246635; cv=pass; d=google.com; s=arc-20240605; b=M8PrskZvACwkJd1uYcNgctpL6AkCykBhIT/ESARSJww2myiWP8yurPfhxVKNFgbrIU eEtJViRKH7q8fWBS/O+nqgk/9jWxVhniFPdVBphaIfGydRBij1neIJ28+Ru61GvJiZIO wxe2iwj8EQ/lk4Y+kBi4//cnfWXQrojxxs+TSOo8CpJn5Ak/TQptEJCJUVcoAHvGpWrB GwE5cL04kS9+BGM9/RiaWDgS+56uKbRkk0M8GNrPuZs4+ZodTtNhuaBfiSQCWoatay1X 9aMqtQga06ewjmKW6Ie9pGcaBsJZFPJ6GUePzpy+iPobsU8fvTomMS/riw0U0J5QcQLF 4o5A== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=FPUOjjTWfilO9Xd5pW8BWhdOUqynOhiAEpCxNAuII6s=; fh=DMP0F9ULS1guKiqimntQRCN8ZraraesEgQuVcn7F0Z0=; b=iGzjbrb7/q9GH8y9uYq7a/jlMTEmbViaczFPxwVsQ26YESqCZa6KPuvHJHxcIi1FD2 84gvILb23SGQsk1k9Y+5x931kj0TkPmUEUClCqtHmymaQUmTcjz7LkP78Ke2hxV5h1wM vEOQULA8OMkycE7+/cPkBXUgHFbLK98kBkmg+nkCXf8hMUx1oB+CTaiiWhQRFU7ag+60 FJ52IOff/PWQb1HK9pwUhpWmF08xKa7eSEOEGkHl3tvSKAuwjCqhoQieVx+hj+sSBI/8 X1e4tNEYM7zFaOcxPabP5CKH99qyv+8M8/ZVaZdJpiwhCWjmG+XwUh6t0ailVSusz4oQ /Ghw==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=T36Ywdls; arc=pass (i=1); spf=pass (google.com: domain of jasonresch@gmail.com designates 2a00:1450:4864:20::531 as permitted sender) smtp.mailfrom=jasonresch@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com. [2a00:1450:4864:20::531]) by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-45e8ad2c11esi79021f8f.1.2026.05.19.20.10.35 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 19 May 2026 20:10:35 -0700 (PDT) Received-SPF: pass (google.com: domain of jasonresch@gmail.com designates 2a00:1450:4864:20::531 as permitted sender) client-ip=2a00:1450:4864:20::531; Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-6870ad8072eso1535347a12.0 for ; Tue, 19 May 2026 20:10:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1779246634; cv=none; d=google.com; s=arc-20240605; b=femILQF+y+uKyjYNPQoRVtyVZD4/ek7oEVlSVONjqmLTD6Q4YnZxFo+YlXPBDQuxi1 Nnz0BeT7oShoLQl5B559b2D6rahX/68A+p97O7zsStAGOoht/4SnSqW1UJrhaUde64/t 4ojcgzbpkID2ZM8EJTiEUza5/CviQUJMj5MafoYTWYbR5GHRQ8W6koI15NMEamuFxW0n 4Bu5KaedvzH8ZRpC1bgfjnUU8al7LBVTFt2XhbXsZ1wAOkL0gjhsgo91DBtCDNoCRsc4 lNl59zAL6RfJH/Do8KzGFMzmknrSUeF3OMoXzCUsHTYC9g7x47UdLx/ASQEMx78Cw9EC tEDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=FPUOjjTWfilO9Xd5pW8BWhdOUqynOhiAEpCxNAuII6s=; fh=DMP0F9ULS1guKiqimntQRCN8ZraraesEgQuVcn7F0Z0=; b=eHrrG1z0Hdow+Iq8drj3rAcxUf7kprq5Um4kk7X+GxpTBbljwD6rUNyLB5yi2TcG7U M3mjOHdXTnrC9L7GUdFOtez5xwtKfAmC40zvsneN4pf1J4YojM9bV0L+1/6mOzbw9WIq C4KTvZ8Yfsq7AKFH7NrK9lgDsJjceOgTv7TZoHLdhz21oH3JwFMtoT0tpV5/b7QegvuV DiL1SVzJBfo271qubKHhYdINr6PYTZEE6ANYrtTAxF6mfNlocc1KJC+c2ebFjXKgYnwo O8vLvMv0Z+/KR4sWXtLgO6h1O9tYE1WO4nY7jVKkNhXTQ38FTAfGm6wO2kzQ8fi06sDx Z/Aw==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: Acq92OEe3i9gg6rpADtV8lAb7xNHnW9NTzGTXilE4Q3qmNGUkuKaBQ2bUxJaontSgdz 484ZsceJTPAiYGz2tBpOWaNRm62V6d67NKaPj0LRB8dukmEbIuEl1epDW5YNDzoW/2wjl/nG1jz zcpMhOnESeufSOQZWyyazU3y3LOXX4M0qv05mJKdme/76UWydLhuQMp8cp6czDuAcEN3iA1C7Bz cqXLK35QyFacxc2Db6wiu20YL/KxfnGd26UFFmkVLF4r2lNyvtV+f570+sC/+sKQgPsGZn4ebQT M1Wzhg/sflgOPYGBsZ5PxxieXE+AVUGSiizxYabs X-Received: by 2002:a05:6402:2807:b0:67e:9cd6:c68f with SMTP id 4fb4d7f45d1cf-683b41cbf3dmr10749825a12.7.1779246634001; Tue, 19 May 2026 20:10:34 -0700 (PDT) MIME-Version: 1.0 References: <8d22c782-6da1-46f3-aa12-f686d5e1746dn@googlegroups.com> In-Reply-To: From: Jason Resch Date: Tue, 19 May 2026 23:10:20 -0400 X-Gm-Features: AVHnY4KnFE-B0ccsVCH75hpQQbjJeBSxHIt9OfsoKHrjYuMhhyeglkEHgtPLlg4 Message-ID: Subject: Re: [bitcoindev] A "Quantum-Agile" Bitcoin address proposal To: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="00000000000096698f06523723ee" X-Original-Sender: jasonresch@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=T36Ywdls; arc=pass (i=1); spf=pass (google.com: domain of jasonresch@gmail.com designates 2a00:1450:4864:20::531 as permitted sender) smtp.mailfrom=jasonresch@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 (/) --00000000000096698f06523723ee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Pieter, Thank you for your illuminating feedback, I very much appreciate it. My replies are in-line below: On Tue, May 19, 2026 at 3:31=E2=80=AFPM Pieter Wuille wrote: > Hi Jason, > > I think that in technical terms, this is how many people already think > about 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 possible to have multiple schemes in parallel. > Thank you for pointing out these alternatives to me. Is it correct that the script Merkle tree would have the additional overhead of: script opcodes, the script itself, the control block, and 32 bytes for each step in the Merkle path? In the proposal I shared, the only overhead (beyond the public key(s) + signature(s) inherent to both) would be only a few bytes of metadata for algorithm specification (which seems necessary in any multi-algorithm implementation). So while the script tree offers more general flexibility, it may be overkill compared to a more basic built-in support for multi-algorithm signatures. > > However, I would not consider this "agility", but rather a necessary evil > as the significant trade-offs in PQC schemes today (large signatures, hig= h > validation 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. > I agree about PQC being a necessary evil. In an ideal world ECDSA would be secure against quantum computers, or failing that, there should be a PQC algorithm just as short, efficient, flexible, and vetted as ECDSA is. But unfortunately no current PQC candidate is as good as ECDSA in all those respects. Faced with that limitation, we must bite the bullet and plan for a CRQC world. How would Satoshi have designed bitcoin if CRQCs already existed, and no PQC was fully trusted to go 20-50 years without failing to cryptanalysis? I think having support one or two alternative fallback algorithms is good insurance in case a common or popular algorithm fails. It is a small cost to pay and would help many Bitcoiners to sleep better at night. Asymmetric ciphers have a poor track record of appearing secure at first, before catastrophically failing (Knapsack , SIKE , NTRUSign ). Given the comparatively short history of PQC algorithms, I think safeguards are another necessary evil in case such a break impacts Bitcoin. > > In fact, I would go as far as claiming that to some extent, the more > schemes are available, the less cryptographically agile Bitcoin becomes, > assuming those schemes are actually adopted. This is because unlike in > TLS/SSH/IPSec, one does not solely care about protecting their own > connections/coins, but 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 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. > That leaves two options, as I see it: A) Support a single PQC algorithm. (And hope no weakness is ever discovered in it as then everyone would be screwed as there would be no quick mitigation.) B) Support multiple PQC algorithms. (And users who are extra security conscious can use at least 2, to protect themselves from catastrophic breaks, while users who use only one will at least have an immediate mitigation path available: they just need to send their vulnerable coins to a new address secured by a remaining unbroken algorithm). I wholeheartedly agree with your sentiment that it is an ugly solution to not have a single well-vetted PQC algorithm to recommend everyone use. But given that we at present do not have one for the CRQC era, I would feel much better as an end user to know there is an available mitigation plan in the case an algorithm is broken. > > 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* 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 > migrate to them. But I think it is misleading to consider such flexibilit= y > a positive property. > Like Churchill said of Democracy, it is the worst option, aside from all the others. Today, Bitcoin gives end-users ultimate decentralized control over how they secure their wallets. Some take it to extremes and use multi-sig, and custodians, or secret sharing across hard wallets, while others might keep their keys in plain text on their internet-connected computers or re-use addresses and expose their public keys to the world. But today, end-users have no control over what algorithms to rely on. So long as all provided options are considered secure enough to pass NIST certification, why not allow some users to choose to use longer keys, or multiple algorithms in combination, should they want to take that extra step for themselves? If the reasoning is: "one of those algorithms might break", that very same reason (in my mind) justifies not having Bitcoin depend on any single algorithm (or algorithm family). > More detailed comments inline below. > > On Tuesday, May 19th, 2026 at 2:43 PM, Jason Resch > wrote: > > 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. > > > I agree that's what may well happen, but for different reasons. If there > somehow 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 that and nothing else. > What are the thoughts here on SQIsign 2.0 ? My understanding is that it is 30X faster than the original SQISign, and this version is now being evaluated by NIST. Its public key is only 2X ECDSA, and its signature is only 2.3X, while its verification time is 5.1 million ops (approximately 1.5 ms on a 3.4 GHz CPU). If there were only one PQC signature algorithm to choose, this one seems to have good trade offs (but it is still so new that I wouldn't feel comfortable trusting it alone and there not being any alternative to switch to). > Such a scheme is unlikely to exist, so we may be forced - possibly over > time - to adopt multiple schemes for different use cases. Still, the choi= ce > between them will follow guidelines, or practically speaking, > wallet/provider implementation, not end user choice. > I agree, and say something similar in section 6 of my proposal: "A quantum-agile Bitcoin wallet would not ask every user to understand every cryptographic family. It would expose a small number of understandable profiles while still allowing expert and institutional users to choose custom all-of-N key bundle." I then provide several example user profiles that wallet provides could suggest to end-users to choose from. > > > 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. > > > This is effectively what the BIP341 script tree already gives you, if > multiple PQC opcodes were added. > I am very relieved and happy to hear that such proposals are already under consideration! > > > - Users who want higher assurance can use heterogeneous algorithm > families, while users with lower-value or high-frequency wallets can c= hoose > cheaper single-algorithm profiles. > > > While that is what may practically happen, I don't consider this a good > thing, 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. > > > 2. It enables rapid migration to other algorithms, should any future > cryptographic break or even suspicious of possible future breaks, occu= r in > the future, without having to wait for a new consensus for a change to= the > Bitcoin 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 that ~everyone moves away. Due to the need for consensus on > which schemes are secure, I'd call Bitcoin pretty much the least > cryptographically agile system imaginable. > I don't think much thought has ever been given to the problem before. ECDSA was the obvious choice in 2008. But newer, more efficient, and more secure algorithms have since become available (e.g. Ed25519). I attribute the lack of change more to inertia than to a lack of consensus on Ed25519's security. Now that CRQCs loom, we have a general consensus that ECDSA will soon no longer be secure, yet there is a general lack of consensus regarding which PQC algorithms will survive cryptanalysis over the long term. This lack of consensus here is not limited to Bitcoin or its users, nor is it anything we can hope to solve from our present vantage point. Only time will tell. > > > 3. End users can choose security levels that correspond to their > security needs and spending habits. Have a cold-wallet securing millio= ns of > bitcoin which you spend from once per decade? Use several PSQ algorith= m > families with large key sizes, and pay higher transaction fees for tho= se > 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 transa= ction > fees. > > > Sure, and this is especially relevant with the recent work on stateful an= d > stateless hash-based signature schemes, which have significant trade-offs > for cost and security that depend on the use case. Still, like above, I > don't consider that an inherently positive property, but an unfortunate > necessity. > I agree. If we do nothing and continue using ECDA, then CRQCs will destroy trust in Bitcoin, so we must add support for PQC. Given that, we can bet the farm on a single PQC algorithm, or we can hedge by supporting multiple PQC algorithms. I don't envy the decision you and the other Bitcoin developers must make, I only hope that I can help make your decision easier by sharing my perspective. Best wishes, Jason --=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/= CA%2BBCJUgfB1iYcxivr0%3DaWORUHVpQ-fTLs47yYDb5aXaTEbBrkw%40mail.gmail.com. --00000000000096698f06523723ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear=C2=A0Pieter,

Thank you = for your illuminating feedback, I very much appreciate it. My replies are i= n-line below:


On Tue, May 19, 2026 at 3= :31=E2=80=AFPM Pieter Wuille <= bitcoin-dev@wuille.net> wrote:
Hi Jason,

I= think that in technical terms, this is how many people already think about= PQC adoption. Most proposals (including P2MR and P2TRv2) are built on the = script merkle tree construction introduced in Taproot. By having multiple l= eaves in the tree, with distinct PQC (or EC) keys/opcodes in each, it is po= ssible to have multiple schemes in parallel.

Thank you for pointing out these alternatives to me. Is it correct = that the script Merkle tree would have the additional overhead of: script o= pcodes, the script itself, the control block, and 32 bytes for each step in= the Merkle path?

In the proposal I shared, the on= ly overhead (beyond the public key(s)=C2=A0+ signature(s) inherent to both)= would be only a few bytes of metadata for algorithm specification (which s= eems necessary in any multi-algorithm implementation). So while the script = tree offers more general flexibility, it may be overkill compared to a more= basic built-in support for multi-algorithm signatures.
=C2=A0

However, I would = not consider this "agility", but rather a necessary evil as the s= ignificant trade-offs in PQC schemes today (large signatures, high validati= on costs, lack of features like homomorphic derivation, low confidence, or = combinations thereof) make it so that there is unlikely to be a single sche= me that covers all needs.

I agree abo= ut PQC being a necessary evil. In an ideal world ECDSA would be secure agai= nst quantum computers, or failing that, there should be a PQC algorithm jus= t as short, efficient, flexible, and vetted as ECDSA is.=C2=A0But unfortuna= tely no current PQC candidate is as good as ECDSA in all those respects. Fa= ced with that limitation, we must bite the bullet and plan for a CRQC world= . How would Satoshi have designed bitcoin if CRQCs already existed, and no = PQC was fully trusted to go 20-50 years without failing to cryptanalysis?

I think having support one or two alternative fallb= ack algorithms is good insurance in case a common or popular algorithm fail= s. It is a small cost to pay and would help many Bitcoiners to sleep better= at night. Asymmetric ciphers have a poor track record of appearing secure = at first, before catastrophically failing (Knapsack, SIKE= , NTRUSign). Giv= en the comparatively short history of PQC algorithms, I think safeguards ar= e another necessary evil in case such a break impacts Bitcoin.

=C2=A0

In fact, I would go as far as claiming that to some ext= ent, the more schemes are available, the less cryptographically agile Bitco= in becomes, assuming those schemes are actually adopted. This is because un= like in TLS/SSH/IPSec, one does not solely care about protecting their own = connections/coins, but also other users' coins: if you believe many coi= ns are held in insecure output types, you're likely worried about the e= ffect 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 a= spect, and makes it effectively a tragedy of a commons: everyone has an inc= entive to make everyone's coins secure.

=
That leaves two options, as I see it:
A) Support a sin= gle PQC algorithm. (And hope no weakness is ever discovered in it as then e= veryone would be screwed as there would be no quick mitigation.)
= B) Support multiple PQC algorithms. (And users who are extra security consc= ious can use at least 2, to protect themselves from catastrophic breaks, wh= ile users who use only one will at least have an immediate mitigation path = available: they just need to send their vulnerable coins to a new address s= ecured by a remaining unbroken algorithm).

I whole= heartedly agree with your sentiment that it is an ugly solution to not have= a single well-vetted PQC algorithm to recommend everyone use. But given th= at we at present do not have one for the CRQC era, I would feel much better= as an end user to know there is an available mitigation plan in the case a= n algorithm is broken.
=C2=A0

Bitcoin is, in m= y 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 of them to be secure. That does not me= an we cannot add schemes of course; obviously any 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 flexibility a positive property.=

Like Churchill said of Democracy, it= is the worst option, aside from all the others. Today, Bitcoin gives end-u= sers ultimate decentralized control over how they secure their wallets. Som= e take it to extremes and use multi-sig, and custodians, or secret sharing = across hard wallets, while others might keep their keys in plain text on th= eir internet-connected computers or re-use addresses and expose their publi= c keys to the world. But today, end-users have no control over what algorit= hms to rely on. So long as all provided options are considered secure enoug= h to pass NIST certification, why not allow some users to choose to use lon= ger keys, or multiple algorithms in combination, should they want to take t= hat extra step for themselves?=C2=A0If the reasoning is: "one of those= algorithms might break", that very same reason (in my mind) justifies= not having Bitcoin depend on any single algorithm (or algorithm family).




More detailed comments inline below.

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

I agree that's what may well happen, but for different= reasons. If there somehow was one PQC scheme that everyone considered secu= re and supported all the features we needed, I am staunchly of the opinion = we should be adding that and nothing else.

What are the thoughts here on SQIsign 2.0? My understanding is that it= is 30X faster than the original SQISign, and this version is now being eva= luated by NIST.=C2=A0Its public key is only 2X ECDSA, and its signature is = only 2.3X, while its verification time is 5.1 million ops (approximately 1.= 5 ms on a 3.4 GHz CPU). If there were only one PQC signature algorithm to c= hoose, this one seems to have good trade offs (but it is still so new that = I wouldn't feel comfortable trusting it alone and there not being any a= lternative to switch to).

=C2=A0
Such a scheme is unlikely to exist, so we = may be forced - possibly over time - to adopt multiple schemes for differen= t use cases. Still, the choice between them will follow guidelines, or prac= tically speaking, wallet/provider implementation, not end user choice.

I agree, and say something si= milar in section 6 of my proposal:
"A quantum-agile Bitcoin = wallet would not ask every user to understand every cryptographic family. I= t would expose a small number of understandable profiles while still allowi= ng expert and institutional users to choose custom all-of-N key bundle.&quo= t;
I then provide several example user profiles that wallet provi= des could suggest to end-users to choose from.

=C2= =A0


In short:
  • A wallet choo= ses one or more public keys from one or more approved signature algorithms.=
  • This ordered public-key bundle is serialized canonically and hashe= d to form the address.
  • Senders do not need to know which algorithm = or algorithms are behind the address.
  • At spend time, the spender re= veals the public-key bundle and provides one valid signature for each key i= n the bundle.

This is effec= tively what the BIP341 script tree already gives you, if multiple PQC opcod= es were added.

I am very = relieved and happy to hear that such proposals are already under considerat= ion!
=C2=A0

=
  • Users who want higher assuranc= e can use heterogeneous algorithm families, while users with lower-value or= high-frequency wallets can choose cheaper single-algorithm profiles.
    • <= /ul>

While that is what may practical= ly happen, I don't consider this a good thing, because of the tragedy o= f the commons here. Users who own small amounts that move frequently would = likely rather see others adopt PQC rather than themselves.

  1. It enables rapid mig= ration to other algorithms, should any future cryptographic break or even s= uspicious 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= .

I do not consider the abi= lity for individual users to move their coins over to something else "= migration", unless there is a reasonable expectation that ~everyone mo= ves away. Due to the need for consensus on which schemes are secure, I'= d call Bitcoin pretty much the least cryptographically agile system imagina= ble.

I don't think mu= ch thought has ever been given to the problem before. ECDSA was the obvious= choice in 2008. But newer, more efficient, and more secure algorithms have= since become available (e.g.=C2=A0Ed25519).=C2=A0I attribute the lack of c= hange more to inertia than to a lack of consensus on=C2=A0Ed25519's sec= urity. Now that CRQCs loom, we have a general consensus that ECDSA will soo= n no longer be secure, yet there is a general lack of consensus regarding w= hich PQC algorithms will survive cryptanalysis over the long term. This lac= k of consensus here is not limited to Bitcoin or its users, nor is it anyth= ing we can hope to solve from our present vantage point. Only time will tel= l.
=C2=A0
=

  1. End users can choose= security levels that correspond to their security needs and spending habit= s. Have a cold-wallet securing millions of bitcoin which you spend from onc= e 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 k= ey size possible to save on transaction fees.
<= div>
Sure, and this is especially relevant with the recent work on state= ful and stateless hash-based signature schemes, which have significant trad= e-offs for cost and security that depend on the use case. Still, like above= , I don't consider that an inherently positive property, but an unfortu= nate necessity.

I agree. = If we do nothing and continue using ECDA, then CRQCs will destroy trust in = Bitcoin, so we must add support for PQC. Given that, we can bet the farm on= a single PQC algorithm, or we can hedge by supporting multiple PQC algorit= hms. I don't envy the decision you and the other Bitcoin developers mus= t make, I only hope that I can help make your decision easier by sharing my= perspective.

Best wishes,

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/bitcoindev/CA%2BBCJUgfB1iYcxivr0%3DaWORUHVpQ-fTLs47yYDb5aXaTEbBrkw%= 40mail.gmail.com.
--00000000000096698f06523723ee--