From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 20 May 2026 07:23:17 -0700 Received: from mail-oa1-f57.google.com ([209.85.160.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wPhpM-0006rZ-8I for bitcoindev@gnusha.org; Wed, 20 May 2026 07:23:17 -0700 Received: by mail-oa1-f57.google.com with SMTP id 586e51a60fabf-439bb670a3csf5017576fac.2 for ; Wed, 20 May 2026 07:23:16 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1779286986; cv=pass; d=google.com; s=arc-20240605; b=NyNwEgTbS1VwRYM5BmUOSUPop+ZXhMuPr3mBWCxorXMnek1lJC3Ap5OIlIVqtqj3lG JMXBUmdMBFenclltFOBEDxoc2GTqPRUbh4lnyfxeUupqYFH0dK2fYqUfwQThXMpNG3fg aJJcsM7e8SA4BRJaIEm/xeLee/J10nOUxWwFU6E4I75QtP3i0y6XtYuFcMRMHxm3k6nH nJIKsnFH5vVTchYon9eo3oIYVR8onr0e55Xi8WaA+pVI6P0U48GFb0+x964ZbScVO+nj ZQlfVOKCO5wDYbK1E7qAdty+eg3OtFEl4IftUCbxyelHWmNKyPrX6zvSU72ZLI2fmSSg xo4Q== 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=EHzHFmxY4lsLX+uZRAVZO9dKZ89FiMPqYmZeKiej8GE=; fh=S0ga8Ke9ZXNnIfDZ6z3noLg1lPZlEYI3kIc0ZHFeAnA=; b=MygCOmm7D4caGzcMwRQiPrPdkyBaOFOS7QhEkeiVwBcNlNhoZiDoJucKd4U1gjO9Ix aRSkXOaA8m8pP/uOzUMiwg7mDX4UnYzXIG5OLhp0VGLeKZI/Rgb/4GOlg+SS54FXvg8J M3spX2lTaQs6UrVfQY7z7RbP2eXc6xiC4Kyi+pkqUpbFXCzcsGlUCz/mPxWrOJ+EFJkZ 74XXqXGNTcXGEUZWGb9ofxXkQUYZJQQOYfji45CL0KFX2JGalK97xUfJv4P/IFweAjNT Cy2zPX+KU64ZIL8rBJ3jxOAkHQrEuxJRazlJhUceqTQj6qi3aPjLrVPYYUTQ7O/s3m3m eyig==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=Kdh17PKd; 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=1779286986; x=1779891786; 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=EHzHFmxY4lsLX+uZRAVZO9dKZ89FiMPqYmZeKiej8GE=; b=fXRIOuZQgNssyaW9WKOSV27HSDgYUsV3WYDx0Z9eVXbO/oVyJFCUBU59uS8I/JpgT/ ZdtXRrm+HwzLEb0M+JmP1JSxbKkgmhq2s+jg5MOulC5aV2lPQH7MMjD5D4M1S66kDMAs +8Doc+G6y5NUd4eR2l7SVzU4VAFDQWEpIAPfgmTyqIsNAnQT1tjUCuTYD8IU06CNGSRq /Dp4rrv3Tl+tVkiMybT+4p22fq7wttuxVaqk4BOCiW0S6r9L8VI4zCCMLs9kLmyiGRjf SGX2ps63NyRiE/BOH6patyGYQOxfpLbSgvF3eFtBDg3P+HSxJ8sEGKU/vNLhR/8ocmE0 5ojQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779286986; x=1779891786; 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=EHzHFmxY4lsLX+uZRAVZO9dKZ89FiMPqYmZeKiej8GE=; b=ZT/93vG7/kQPNg290G5+m52Mhsz9dfylq0WXFz/aLDD1lp/nyUFo+cFtqGFAJkAZI2 TsNJgSN5iopPZYqL18Fa3L4qoMa2F8hPbSBxpv4FqQhDoqqks+DM886JDQ/BzDtq1S+B Bv1RjrA7W2RIUM7AR9yU2fKuKYJXT9+2m+po/xgixHcbUQ8Pk4toHTZSTVqeWKAtaMPU Uj/79GPPeVxUj2pSloemZA+vxKFLdwXUiIcnrYsYvUGb2H6zw52lpi1YzCNQYcCwXEf9 rxcBgHt7NChFolIN3vxLwgEI13jqmtfbEuRP8PgxFeSDu3YEMSOM22wfVt+AKnwjYRwf A5Og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779286986; x=1779891786; 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=EHzHFmxY4lsLX+uZRAVZO9dKZ89FiMPqYmZeKiej8GE=; b=aStiG4SeMACC2vwvDEDXt+V2m9VBKGJ19Y5GYVuw9pTv2Q+PDgpRjUIUnYmwa1W4yJ ALyBQWsaeZmWvx5pNQdun54213Omp+BzhdQ6gOaWnCBcEiYfpKuS3dB69pjD/wjuTK1c kFTUTLPPq4jH38eEccbTRdIQGzlv80/qbygzLf6IKXZu3Kcp4hRiMZaIIZ4FR+TgSRCf CIiWtMOlSsp/cNwIvt3TOzXiOoUkEBuOVJHV3wFzubmxSKKEc+M0ZRkWeWlzOzwiEx9G CpeYKAcG4xv/Dzut8i2f8iExrh6xIViMrrHj8VcHWgZ4mupXjLI05bMKSas3LDJt7VOc B2xA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AFNElJ/nMKVYQNCH8kD5Hf0gtjOF8WUlvz6k92MKyR93539fsJiYg3BjM0Z3T4K/vDzV+bPok6xalU8psIGv@gnusha.org X-Gm-Message-State: AOJu0YwbBmEgYYVN/eqJYLbKgDi2XGcObNzt8zgSWhJc09zMUbsfoq/0 cw0MdPvemkU2PtgwsiWyuj62UTyQzg2f2pEc8cs6sZt3NzucHvTxRm61 X-Received: by 2002:a05:6870:9708:b0:41c:6ded:291c with SMTP id 586e51a60fabf-43a2de07ad2mr15664480fac.35.1779286985432; Wed, 20 May 2026 07:23:05 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMNzU0EtMTd+OzsUOCG6Ion+lmVtQ1rqFcCB/qs1hCdlVA==" Received: by 2002:a05:6870:1606:b0:439:b6fe:4488 with SMTP id 586e51a60fabf-43a01ebc7fels7360109fac.2.-pod-prod-05-us; Wed, 20 May 2026 07:23:00 -0700 (PDT) X-Received: by 2002:a05:6808:e68f:b0:47c:3793:c589 with SMTP id 5614622812f47-482e5729f77mr11458764b6e.26.1779286980215; Wed, 20 May 2026 07:23:00 -0700 (PDT) Received: by 2002:ab3:7f13:0:b0:2e5:dca6:8eb2 with SMTP id a1c4a302cd1d6-3011290ac33msc7a; Wed, 20 May 2026 07:20:23 -0700 (PDT) X-Received: by 2002:a05:651c:198a:b0:393:a0f0:57f7 with SMTP id 38308e7fff4ca-39561d62695mr83251281fa.14.1779286822324; Wed, 20 May 2026 07:20:22 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1779286822; cv=pass; d=google.com; s=arc-20240605; b=N2lH4849hJcVrv6/BL91oDkPZiFtEJqCcOzIJCNjsx+8kboNT7nBi5R7ylIs7kv2dv 5TUz9tYMdhwfrEjNgolZSThUVA1f27PAI8NPDiAjlBxlI7DLev2Of4Gsu85RezSBIA3h 5XCAbPNecQy4pkRjexeN+YTQiWCiK7cp68s+KVe21sj5WdnCKUHarD/WnZXTEPGAuYHq ceqMy1xvaFRQuKKKQx2j+Ji1EPXBlUydhsRRy1I66h/p6Qre348mRZYPKPFN8CGwcqjQ oU60sV6GBs6PzCuLEM8TobA9K7EX/mJj18e8S3lXNvxsdMaDP5fNjD5dkMEDJ58otpH6 V3Pg== 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=tfXsCQb0EvtVY6hsQ/ov7z25ioLeLrBkH+YWOR7Q2L4=; fh=DMP0F9ULS1guKiqimntQRCN8ZraraesEgQuVcn7F0Z0=; b=fLpcj+DIw7zvZxR2AnlRqNVaFceL/Tg1y8ubsLo+UutevtxQW3W/epJ0raA62zZ65P hrt7tij8EIoii/k+ZoGqiHZen2Kp5+Qy6MtSCEcArxzOKUdvDB6qg4+WxsF45PLec/zI lCPx/epTrpiUo2wSdzJCa1xfSPUu91QqHpXaqhtkYst81rfGHSjomdtLQbaBmVUbK19N FH8q7l+VCgOzmT4X/AYPDh07WflHrTM/7lLqLaVOCiUdS7837rMZeDVDQOln2ZWH1yOb r0aRZ69EJh/rAzioksMbQDR/emTwI4HU5l9jQXUcBmZgEFZXVZmcW8Gai8Vkk/pRyEFP FFjA==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=Kdh17PKd; 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 38308e7fff4ca-395882b1f5csi2045691fa.1.2026.05.20.07.20.22 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 20 May 2026 07:20:22 -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-6802f9c5debso11151878a12.3 for ; Wed, 20 May 2026 07:20:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1779286821; cv=none; d=google.com; s=arc-20240605; b=Y4KETgi9bRUW/THv/h3o8cWrSDj6DXr2QnNHVcY5iKEB5eDXb1NHl7WnmB6/1mNoIs nF05WzaRtQ3yrMsbbbggeylwESqaeHkv52NqVkajJlMahwZXWl+/9LICs0cZlq192DU3 b2sCr/bpSInydGQ7mEmJ+qrO48VTru8jUpEgTLBHQ9V7T00zpiYqPNfuJLGw4AD56AWa G1v8V8YdJ1J00Zm0jFJ0h0DHc0d14jg8cIB+EeT7cEojP+kXd8pioEfWPfHrq4FhSM62 39bVsYjR5l3gdisYawHf63v3ad8/hOyUhMcB3ArKUM0koS5UqisJYPMiWyehLnrOmGPG 21ew== 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=tfXsCQb0EvtVY6hsQ/ov7z25ioLeLrBkH+YWOR7Q2L4=; fh=DMP0F9ULS1guKiqimntQRCN8ZraraesEgQuVcn7F0Z0=; b=H53Am243Ob3BZx46k/1hI2PLtKqrMEESkNGFMpM1Q5pelV3+vgZfFcog44f/3cyE8E mkaJMlo1gqw8RHRDjRVd+TZxyj2djRIUT5z3kyNEGeBi/K/wYVmVDRwtDCdui5OZGHE5 l53I0+YiSCP/RESgcGDGygU+sno57/1XVY8CZY4NuVAvI04Dpx5/8YpR4F/oNmwYBvMp A3qzXOuXfrFh4Qc6PSx2/oAox72NlAsp005Qh0iNwbLkE0gRDZxBmfZZOGNOHTmobD7Z c5Thz12r0gUdcQg2DqDVjZZqVsynlV2/536xYIlSuoXijkT5Z/wOSsos1hoLNydweOdl fpWQ==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: Acq92OG4xdfLnRx0tLfIAOtZ7Sq94ibQq4KLt9NhPysmSL5pZbCk8vGP30Lulug9lfA 3HaPl4K2X2UNMBg63ZtC9ObyAgQUlzm1Nd8x8bH7Bdh5XFvSkJ+Tni88EeIeA64osVBPETlxKWx 5vqwdXGHRILr25mK5rDWmHiDz00On3/VAAt/FXw3Q/9A9qEePjYAyal/Ta4RO0wFypVQFIIloMq uSpWLNQuV8AzURgQQPzHhNbpPAf7TioFhd98JVLE0IP8R6NxRinJ8l9xJ8eCI3xhYxnBQXLPX9F HtTvKjnC0COFpSX0m+Oc7AjaT9BPlz1DyykDDmvo X-Received: by 2002:a05:6402:358e:b0:674:40c3:f047 with SMTP id 4fb4d7f45d1cf-683bcd9eefbmr12809447a12.12.1779286820797; Wed, 20 May 2026 07:20:20 -0700 (PDT) MIME-Version: 1.0 References: <8d22c782-6da1-46f3-aa12-f686d5e1746dn@googlegroups.com> In-Reply-To: From: Jason Resch Date: Wed, 20 May 2026 10:20:10 -0400 X-Gm-Features: AVHnY4KYBjAODpBECdjImCnGi_Jsl6glCdN0l70_HktT4vglHrKYJzdmWfgWQMk Message-ID: Subject: Re: [bitcoindev] A "Quantum-Agile" Bitcoin address proposal To: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000e840fd0652407e21" 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=Kdh17PKd; 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 (/) --000000000000e840fd0652407e21 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 20, 2026, 9:02=E2=80=AFAM Pieter Wuille wrote: > Hi Jason, > > See my comments below. > > On Tuesday, May 19th, 2026 at 11:27 PM, Jason Resch > wrote: > > > 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. > > > I do not believe that is correct. As I understand it, your proposal > requires revealing *all*=E2=80=8B public keys (across all schemes) at spe= nd time, > because the hash in the address commits to their concatenation. Merkle > script tree based solutions only require revealing the actually signed-wi= th > public key type, plus a logarithmic number of 32-byte Merkle steps for th= e > other public key types. The other costs are either marginal or common > between approaches. In Merkle script trees approaches, only one script is > revealed, and (in the single-user setting which you seem to be talked > about) consists of just a public key + an opcode. The 64-byte control blo= ck > is unique to Taproot, but orthogonal; P2MR does not have it for example. = It > allows for one specific public key to be spent with extremely cheaply, at > the cost of making everything else more expensive. > > I believe that If there is at least one alternative key type in the > construction that's larger than 32 bytes, or at least 2 alternative keys, > Merkle tree based approaches will have a strictly lower on-chain footprin= t > at spend time. > Ahh, I think I understand now. If one used multiple algorithms in their original commitment, then at spend time they can choose to reveal only one public key and signature for an algorithm known to be secure at that point in time. That is very elegant. > 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? > > > There is no problem supporting multiple algorithms as long as everyone > trusts all of them - and that is what will likely need to happen in > practice. But coming to agreement on what that is, is part of the problem= , > and not all users might be willing to just trust NIST here to make that > decision for everyone. Allowing users to choose individually between > different "trusted" algorithms has only a marginal benefit: everyone > already relies on none of these algorithms being broken for the currency = to > retain value. Picking a "stronger" algorithm for your own coins means > you're optimizing for a scenario where other algorithms are broken, there > is mass chaos due to theft and likely forks, but somehow your own coins > make it through to the other side in a wasteland. It's certainly reasonab= le > to expect that some individual users would make this choice if available, > but systemically, as protocol designers, it does not seem like an > interesting thing to focus on. > > Again, I'm not arguing against the practical reality of Bitcoin likely > needing to adopt multiple algorithms if migration to a PQC world is neede= d. > I am arguing against user flexibility itself being something to optimize > for. > I am beginning to come around on this, because I had not considered how much more trust already exists for hash-based signatures. If hashes break, then the whole concept of block chains breaks. So hash-based signatures seem to add the least additional security assumptions. All the other signature schemes require additional assumptions about the hardnesses of certain mathematical problems. > If the reasoning is: "one of those algorithms might break", that very sam= e > reason (in my mind) justifies not having Bitcoin depend on any single > algorithm (or algorithm family). > > > The enormous difference is that Bitcoin users *already*=E2=80=8B opted in= to > trusting that algorithm by using Bitcoin in the first place. Adding more > algorithms means expanding the set of trusted algorithms, possibly agains= t > those users' wishes. The threat of CRQCs may make us all reevaluate our > trust in secp256k1's security, which is why we're having this discussion. > That's true and I now understand your point. More algorithms means less total trust in them all working out. Whereas moving to just one signature scheme that had even more trust than ECDSA could make Bitcoin even more trusted. > > 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 th= at > I wouldn't feel comfortable trusting it alone and there not being any > alternative to switch to). > > > I'm really not qualified to comment on this. > > 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. > > > I strongly disagree with this. The security difference between ed25519 an= d > secp256k1 ECDSA is marginal. They are both based on hardness of the ECDLP > problem. The secp256k1 curve has some unusual structure that may make it > weaker than generic curves, though this is a theoretical concern right no= w. > On the other hand, the ed25519 curve is slightly smaller, which should ne= t > it around 1.2 bits less security (also marginal). In theory, ECDSA may ha= ve > weaknesses over Schnorr (which ed25519 and bip340 are instances of) in > addition to their respective ECDLP hardness, but this is very theoretical= . > > But even ignoring the security distinction between the two, needing to > trust both is worse than just trusting one, which IMO means there was nev= er > a justification for adding ed25519. > That's a good point. I can agree then there never was sufficient reason to change the protocol to add support for it. And migrating fully to ed25519 (removing secp256k1 from the trust equation) > would have come at a cost that isn't justified by the distinction between > them. It is only due to the CRQC threat that we are now in a position tha= t > forces bearing that cost. > > I agree. If we do nothing and continue using ECDA, then CRQCs will destro= y > 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 multipl= e > 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 easi= er > by sharing my perspective. > > > This is not a decision that is up to developers, but up to the entire > ecosystem. Certainly some people's opinion carry more weight than others, > but software developers can only release software, not force people to us= e > it. By participating in this discussion, you too are part of the reasonin= g > that will ultimately guide the ecosystem towards the choice it makes. > Please don't say it's up to some specific group of people to decide. If > that were the case, Bitcoin has long failed already. > I appreciate that. Thank you for taking the time to educate me on this topic. I feel Bitcoin's future remains bright given all the thought the community is directing towards this problem. 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%2BBCJUjN9%3Dprte7_Gfj_j8%3D2zSPfUQVQDm04aatyT7UAZp5i3A%40mail.gmail.com. --000000000000e840fd0652407e21 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, May 20, 2026, 9:02=E2=80= =AFAM Pieter Wuille <bitcoin-d= ev@wuille.net> wrote:
Hi Jason,

= See my comments below.

On Tuesday, May 19th, 2026 at 11:27 PM= , Jason Resch <jasonresch@gmail.com> wrote:

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

I think that in technical terms, this is ho= w many people already think about PQC adoption. Most proposals (including P= 2MR and P2TRv2) are built on the script merkle tree construction introduced= in Taproot. By having multiple leaves in the tree, with distinct PQC (or E= C) keys/opcodes in each, it is possible to have multiple schemes in paralle= l.

Thank you for pointing out these a= lternatives to me. Is it correct that the script Merkle tree would have the= additional overhead of: script opcodes, the script itself, the control blo= ck, and 32 bytes for each step in the Merkle path?

In the proposal I shared, the only overhead (beyond the public key(s) + si= gnature(s) inherent to both) would be only a few bytes of metadata for algo= rithm specification (which seems necessary in any multi-algorithm implement= ation). So while the script tree offers more general flexibility, it may be= overkill compared to a more basic built-in support for multi-algorithm sig= natures.

I do not believe= that is correct. As I understand it, your proposal requires revealing a= ll=E2=80=8B public keys (across all schemes) at spend time, because the= hash in the address commits to their concatenation. Merkle script tree bas= ed solutions only require revealing the actually signed-with public key typ= e, plus a logarithmic number of 32-byte Merkle steps for the other public k= ey types. The other costs are either marginal or common between approaches.= In Merkle script trees approaches, only one script is revealed, and (in th= e single-user setting which you seem to be talked about) consists of just a= public key + an opcode. The 64-byte control block is unique to Taproot, bu= t orthogonal; P2MR does not have it for example. It allows for one specific= public key to be spent with extremely cheaply, at the cost of making every= thing else more expensive.

I believe that If there= is at least one alternative key type in the construction that's larger= than 32 bytes, or at least 2 alternative keys, Merkle tree based approache= s will have a strictly lower on-chain footprint at spend time.
<= /div>

Ahh, I think I understand now. If one used multiple algorithms in their or= iginal commitment, then at spend time they can choose to reveal only one pu= blic key and signature for an algorithm known to be secure at that point in= time. That is very elegant.

<= div>
But today, end-users have no control over what al= gorithms 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 us= e longer keys, or multiple algorithms in combination, should they want to t= ake that extra step for themselves?

=
There is no problem supporting multiple algorithms as long as ev= eryone trusts all of them - and that is what will likely need to happen in = practice. But coming to agreement on what that is, is part of the problem, = and not all users might be willing to just trust NIST here to make that dec= ision for everyone. Allowing users to choose individually between different= "trusted" algorithms has only a marginal benefit: everyone alrea= dy relies on none of these algorithms being broken for the currency to reta= in value. Picking a "stronger" algorithm for your own coins means= you're optimizing for a scenario where other algorithms are broken, th= ere is mass chaos due to theft and likely forks, but somehow your own coins= make it through to the other side in a wasteland. It's certainly reaso= nable to expect that some individual users would make this choice if availa= ble, but systemically, as protocol designers, it does not seem like an inte= resting thing to focus on.

Again, I'm not argu= ing against the practical reality of Bitcoin likely needing to adopt multip= le algorithms if migration to a PQC world is needed. I am arguing against u= ser flexibility itself being something to optimize for.

I am b= eginning to come around on this, because I had not considered how much more= trust already exists for hash-based signatures. If hashes break, then the = whole concept of block chains breaks. So hash-based signatures seem to add = the least additional security assumptions. All the other signature schemes = require additional assumptions about the hardnesses of certain mathematical= problems.



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).

The enormous difference is that Bitcoi= n users already=E2=80=8B opted into trusting that algorithm by using= Bitcoin in the first place. Adding more algorithms means expanding the set= of trusted algorithms, possibly against those users' wishes. The threa= t of CRQCs may make us all reevaluate our trust in secp256k1's security= , which is why we're having this discussion.

That's tr= ue and I now understand your point. More algorithms means less total trust = in them all working out. Whereas moving to just one signature scheme that h= ad even more trust than ECDSA could make Bitcoin even more trusted.



=

What are the thoughts here on SQIsign 2.0? My understanding is that it is 3= 0X faster than the original SQISign, and this version is now being evaluate= d 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, thi= s one seems to have good trade offs (but it is still so new that I wouldn&#= 39;t feel comfortable trusting it alone and there not being any alternative= to switch to).

I'm r= eally not qualified to comment on this.

I d= on't think much thought has ever been given to the problem before. ECDS= A was the obvious choice in 2008. But newer, more efficient, and more secur= e algorithms have since become available (e.g. Ed25519). I attribute the la= ck of change more to inertia than to a lack of consensus on Ed25519's s= ecurity.

I strongly disag= ree with this. The security difference between ed25519 and secp256k1 ECDSA = is marginal. They are both based on hardness of the ECDLP problem. The secp= 256k1 curve has some unusual structure that may make it weaker than generic= curves, though this is a theoretical concern right now. On the other hand,= the ed25519 curve is slightly smaller, which should net it around 1.2 bits= less security (also marginal). In theory, ECDSA may have weaknesses over S= chnorr (which ed25519 and bip340 are instances of) in addition to their res= pective ECDLP hardness, but this is very theoretical.

<= div>But even ignoring the security distinction between the two, needing to = trust both is worse than just trusting one, which IMO means there was never= a justification for adding ed25519.
<= /div>

That's a good point.= I can agree then there never was sufficient reason to change the protocol = to add support for it.

<= div class=3D"gmail_quote gmail_quote_container">
An= d=C2=A0migrating fully to ed25519 (removing secp256k1 from the trust equati= on) would have come at a cost that isn't justified by the distinction b= etween them. It is only due to the CRQC threat that we are now in a positio= n that forces bearing that cost.

I agree. If we do noth= ing and continue using ECDA, then CRQCs will destroy trust in Bitcoin, so w= e 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= 9;t envy the decision you and the other Bitcoin developers must make, I onl= y hope that I can help make your decision easier by sharing my perspective.=

This is not a decision t= hat is up to developers, but up to the entire ecosystem. Certainly some peo= ple's opinion carry more weight than others, but software developers ca= n only release software, not force people to use it. By participating in th= is discussion, you too are part of the reasoning that will ultimately guide= the ecosystem towards the choice it makes. Please don't say it's u= p to some specific group of people to decide. If that were the case, Bitcoi= n has long failed already.

I appreciate that. Thank you for ta= king the time to educate me on this topic. I feel Bitcoin's future rema= ins bright given all the thought the community is directing towards this pr= oblem.

Jason=C2=A0

--
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.co= m/d/msgid/bitcoindev/CA%2BBCJUjN9%3Dprte7_Gfj_j8%3D2zSPfUQVQDm04aatyT7UAZp5= i3A%40mail.gmail.com.
--000000000000e840fd0652407e21--