From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 20 May 2026 06:30:23 -0700 Received: from mail-oi1-f191.google.com ([209.85.167.191]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wPh0A-0006Qv-80 for bitcoindev@gnusha.org; Wed, 20 May 2026 06:30:23 -0700 Received: by mail-oi1-f191.google.com with SMTP id 5614622812f47-47cb35f4e97sf1318398b6e.3 for ; Wed, 20 May 2026 06:30:21 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1779283815; cv=pass; d=google.com; s=arc-20240605; b=NUxhtxBFe84nt0tBKj4fBJtzqCp7wlvt9EGS1wVR0n/EF7FVLR5dkDr8Npyfgmhhey RkoBIo2OnNcMUSVLTUNMHX2agaaQvOT1H8WtZISvFXCPyw3VXLYoj9hQRCfOuWIy9lYO rV8ylAdq5x/vvB8mMLsnGJn6jHOCne9R6wsp2NBDIXwseDVLegg7EICr3cXgArUUB9EW J8OOE5olyfQah3zZwRFjCFz8DbWZkoZZLi7MzmFx2Gt6v4HUbXvyAKihKklxk8zk0Oc0 HJ2nW3Il/U0nkCU5uwX0P9lQba4frJsiGJN+X/o0GElbTQxuA8SNxf/HHkgWPlUHXWhc aP8g== 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=Rde9kMqRCkCK0Ll7PoxUOBXpGC6TBTzQoJsYZoRVeGY=; fh=XOJr4cgjbhq6qUuaxnZpFNZGQX0xF3lO68hlrwxQkVQ=; b=U+Eq+SeCTSuFd3OxvRVpg31GZmPDvbzSkVjEbil+HsJRhQNpsuECsiorBeAUqkb8/Z gqITm2+g1u7y9p3Cg6KXaYPlmwVP07ANoy0AkLKa2Md5WdKxE3SsdSSxqlYtgNH01Lyk H3yvyGztpTJLTEso/uPWvztN2x3PPiS04obHZpm8gbI+Fcnn9y0iuqwLHuNJnuUfk6R/ bLN5iPaA4RwbIeXwnMibYxqY8NPP1fhQ+JvXlgs1znI39M+lYoEZfp+EtRdCQ9ly0bIM aRzc93VqvLuAlcCkZ9DdwVw3co1gxNSDXThmLBCcPWwhtMlim5CVihB3NCo7COjam4UR RJww==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@wuille.net header.s=protonmail header.b=G9cqDzrM; 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=1779283815; x=1779888615; 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=Rde9kMqRCkCK0Ll7PoxUOBXpGC6TBTzQoJsYZoRVeGY=; b=c3RZQXdSuQilCKH1QDM6oUP/mpx4uVndK7NBYhujEY352tNRJ9bHu2sE0f7RrFDNbp B14NdkVcTj6Z7tBaeMEvsdgvf6wxpU/ou6QsY0Q5LmemcODh8pv2uTg2sIKaatdfS+in kaNN4sB1exUSZgZZBAuDP3bcSUTP/zTgYBP1XTuO2Fh2OqpKaC4ztiF0BJb2V2jqYZIP zwsg8s20wkTVH+yF7UopqOB99A6LfFWIUm3RIS9hkIfch8KZTQXZIkaTH5Eb2GsByb2g Ozt0DLV3DSb4Nb2BFUlo/emPx8P6zOdoItCSzD7FUK1epPFemjuMy3lzqBWsNKy+SLEa /qTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779283815; x=1779888615; 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=Rde9kMqRCkCK0Ll7PoxUOBXpGC6TBTzQoJsYZoRVeGY=; b=FwxmqPEvl8Ec9wbWOZ+U9xzVa3tIo4An2+THUUqmnnO0oHozg1zQJ6fdpYQh4OB4fc ntfxjhv6tu6dO/cyAHfva4pDFtcUcL7qYSRTjj1LPiPBlSmjNuYghUecwTJHBzhoglZS yYc4bcoZq+qBgIQAhjWrRWUHHiVBwNJk4qA38ncOBEqVxfTfiAIis+34hlw+WqMnKBUb yaGF/aIO9YnnqrG4n9GzdBOENLd+M4Xx9jOc1d+WeghlgXrDjeHQeeeRd4lNz7MBWw9U Ud9SdVFz9CTbc9e8kavoO8+GzXqxVOA5xcx5dp+a2+1uJfFyWStkJx/TmRSfYAOaGYFi E5Rw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AFNElJ+qp5OvIWxBMfuH3VfZjANcwW2eq3hkOk/hwKCsumT5TBYa5hWCmSki7aLuqAnEDdxxNsl+Y3aWDgKl@gnusha.org X-Gm-Message-State: AOJu0YytyXcp9gdT0ym2HSYBkPCHNO9uGxfJBD2RECyeDbpF+XLi9Sox c9bWFcHysAhl2JJBAJYklueM713AzcAJGw2LYC+41FCOQd7MX5+9K1o8 X-Received: by 2002:a05:6808:350b:b0:46e:c1cd:865b with SMTP id 5614622812f47-482e5663948mr9286071b6e.2.1779283815170; Wed, 20 May 2026 06:30:15 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMPmLm9D8WZq6UkgEAj1dOtLumlZYMS0LqE3pFEtAG2Xug==" Received: by 2002:a05:6871:7c17:b0:430:b76:607f with SMTP id 586e51a60fabf-439cd14f500ls3281323fac.2.-pod-prod-00-us-canary; Wed, 20 May 2026 06:30:09 -0700 (PDT) X-Received: by 2002:a05:6808:3a14:b0:467:e1a8:2b92 with SMTP id 5614622812f47-482e452cf69mr13580615b6e.10.1779283809568; Wed, 20 May 2026 06:30:09 -0700 (PDT) Received: by 2002:a05:6504:10c8:b0:301:8327:726e with SMTP id a1c4a302cd1d6-30183277495msc7a; Wed, 20 May 2026 06:02:35 -0700 (PDT) X-Received: by 2002:a05:6512:1316:b0:5a8:5b19:fd03 with SMTP id 2adb3069b0e04-5aa0e5b9aaemr7119662e87.0.1779282153363; Wed, 20 May 2026 06:02:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1779282153; cv=none; d=google.com; s=arc-20240605; b=WYilLj/NOaU8bQIZ8kwjTgyHjyR9FJRyHoakj6sldN1XMz8oxJVPc3y0ET1CXyzQqg qDNhxNRvf6EnhcYgWF20BNLk3D0qzmI/AGAPTGn/ryV3qY642N8EUn1l+bC654fLTYet HcDe3kRbF+/mO/fpG2JZcg7Kr3Dbaox1ujtvOo1VxrpZm3ZHNzgOKIkQQdIDTPmrvsXI kv/+tsMmeNFQSuRaUcKQWT5eBKrIVNbubLVZB338FXQG+bKuDJcr2OOHzAs0koJwdtUj FEgFPaHtPG1PlyrnwFyTdbq9KVHr1gvWj+VCROxFlwkZHlURS2/0Xh18/Qq323CHRtIK VcFA== 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=/5grxq9yrPQTxSFzokPuhV2UJTP9CAzpgKfTQANfzB0=; fh=aLCQdAC+qOlZswv4b2ODrS4x1FFLLH6Bw8xxp+OpW+E=; b=bJBxUohwcIJZlZe6BQtnIo+4s898G45iUS0SSj+TdsVHTViHP0E6RnDZPmcXeCWXkk CoJbQk4o69XUea6Nnxnc8dlJcjNzf1+lWbwNmDB5PD7GY5WzHK4vHldQfF6US7HYkqAL kup+eoZlLUahjZBR5VsZ5Z5Op0RtXxkF3MevAjbzco0AylWFh70pwAZg5D8kAfv4siC3 vNyHXlxRDgeFeuJ8MeSruUEcv1PGgFrX2cxpk/wnmKiDYuCEVulTuPPNnRaJrPsQEv5c UcnV9quPLJ1Tp1ihAnMcCIV6jKV6W+sCgIUXpeClNz0cFDfWz6uar/WkdWXAXGU+Y+id U3jw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@wuille.net header.s=protonmail header.b=G9cqDzrM; 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 2adb3069b0e04-5a9163a97f5si468136e87.3.2026.05.20.06.02.33 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 May 2026 06:02:33 -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: Wed, 20 May 2026 13:02:23 +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: References: <8d22c782-6da1-46f3-aa12-f686d5e1746dn@googlegroups.com> Feedback-ID: 19463299:user:proton X-Pm-Message-ID: 3e9dadf75325e3331915b9bf82cd06a304788d8d MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_h8Jjbo0FAOXFguxPN4zCryj4dI7NeNrf6QFkiuyQk" 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=G9cqDzrM; 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=_h8Jjbo0FAOXFguxPN4zCryj4dI7NeNrf6QFkiuyQk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 a= bout PQC adoption. Most proposals (including P2MR and P2TRv2) are built on = the script merkle tree construction introduced in Taproot. By having multip= le leaves in the tree, with distinct PQC (or EC) keys/opcodes in each, it i= s possible to have multiple schemes in parallel. > > Thank you for pointing out these alternatives to me. Is it correct that t= he 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 M= erkle path? > > In the proposal I shared, the only overhead (beyond the public key(s) + s= ignature(s) inherent to both) would be only a few bytes of metadata for alg= orithm specification (which seems necessary in any multi-algorithm implemen= tation). So while the script tree offers more general flexibility, it may b= e overkill compared to a more basic built-in support for multi-algorithm si= gnatures. I do not believe that is correct. As I understand it, your proposal require= s revealing all=E2=80=8B public keys (across all schemes) at spend time, be= cause the hash in the address commits to their concatenation. Merkle script= tree based solutions only require revealing the actually signed-with publi= c key type, plus a logarithmic number of 32-byte Merkle steps for the other= public key types. The other costs are either marginal or common between ap= proaches. In Merkle script trees approaches, only one script is revealed, a= nd (in the 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 Ta= proot, 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 mak= ing everything else more expensive. I believe that If there is at least one alternative key type in the constru= ction that's larger than 32 bytes, or at least 2 alternative keys, Merkle t= ree based approaches will have a strictly lower on-chain footprint at spend= time. > 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 cert= ification, why not allow some users to choose to use longer keys, or multip= le algorithms in combination, should they want to take that extra step for = themselves? There is no problem supporting multiple algorithms as long as everyone trus= ts all of them - and that is what will likely need to happen in practice. B= ut 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 e= veryone. 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 scenar= io 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 reasonable to expect that some individual us= ers would make this choice if available, but systemically, as protocol desi= gners, it does not seem like an interesting thing to focus on. Again, I'm not arguing against the practical reality of Bitcoin likely need= ing to adopt multiple algorithms if migration to a PQC world is needed. I a= m arguing against user flexibility itself being something to optimize for. > 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 alg= orithm (or algorithm family). The enormous difference is that Bitcoin users already=E2=80=8B opted into t= rusting that algorithm by using Bitcoin in the first place. Adding more alg= orithms means expanding the set of trusted algorithms, possibly against tho= se 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. > What are the thoughts here on [SQIsign 2.0](https://sqisign.org/spec/sqis= ign-20250205.pdf)? My understanding is that it is 30X faster than the origi= nal SQISign, and this version is now being evaluated by NIST. Its public ke= y 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 w= ere 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 trusti= ng 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. ECD= SA was the obvious choice in 2008. But newer, more efficient, and more secu= re algorithms have since become available (e.g. Ed25519). I attribute the l= ack of change more to inertia than to a lack of consensus on Ed25519's secu= rity. I strongly disagree with this. The security difference between ed25519 and = secp256k1 ECDSA is marginal. They are both based on hardness of the ECDLP p= roblem. The secp256k1 curve has some unusual structure that may make it wea= ker 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 w= eaknesses over Schnorr (which ed25519 and bip340 are instances of) in addit= ion to their respective ECDLP hardness, but this is very theoretical. But even ignoring the security distinction between the two, needing to trus= t both is worse than just trusting one, which IMO means there was never a j= ustification for adding ed25519. And migrating fully to ed25519 (removing s= ecp256k1 from the trust equation) would have come at a cost that isn't just= ified by the distinction between them. It is only due to the CRQC threat th= at we are now in a position that 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 multiple = PQC algorithms. I don't envy the decision you and the other Bitcoin develop= ers must make, I only hope that I can help make your decision easier by sha= ring my perspective. This is not a decision that is up to developers, but up to the entire ecosy= stem. Certainly some people's opinion carry more weight than others, but so= ftware developers can only release software, not force people to use it. By= participating in this discussion, you too are part of the reasoning that w= ill 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. Cheers, -- 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/= VYtAQB0c0TAb_GQlnazB1OE9rtZDe8FsrAOg5YU7R6rZ8Etho2eg5gVJ0kxnwt9Qpln0FxTU3BJ= suwKFqjZOEz15HrF5UwoAxY-G8iIyXxU%3D%40wuille.net. --b1=_h8Jjbo0FAOXFguxPN4zCryj4dI7NeNrf6QFkiuyQk Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jason,

See my comments below.

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

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 prop= osals (including P2MR and P2TRv2) are built on the script merkle tree const= ruction 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 po= inting out these alternatives to me. Is it correct that the script Merkle t= ree would have the additional overhead of: script opcodes, the script itsel= f, the control block, and 32 bytes for each step in the Merkle path?
<= div>
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-a= lgorithm implementation). So while the script tree offers more general flex= ibility, it may be overkill compared to a more basic built-in support for m= ulti-algorithm signatures.

I do not believe that is correct. As I understand it, your proposal requi= res revealing all=E2=80=8B public keys (across all schemes) at spend= time, because the hash in the address commits to their concatenation. Merk= le script tree based solutions only require revealing the actually signed-w= ith public key type, plus a logarithmic number of 32-byte Merkle steps for = the other public key types. The other costs are either marginal or common b= etween approaches. In Merkle script trees approaches, only one script is re= vealed, 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 block is uni= que to Taproot, but orthogonal; P2MR does not have it for example. It allow= s for one specific public key to be spent with extremely cheaply, at the co= st of making everything else more expensive.

I bel= ieve 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 b= ased approaches will have a strictly lower on-chain footprint at spend time= .

=
But today, end-users have no control over what algorithms to rely o= n. So long as all provided options are considered secure enough to pass NIS= T certification, why not allow some users to choose to use longer keys, or = multiple algorithms in combination, should they want to take that extra ste= p for themselves?

There i= s 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 comi= ng 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" algorit= hms has only a marginal benefit: everyone already relies on none of these a= lgorithms being broken for the currency to retain value. Picking a "stronge= r" algorithm for your own coins means you're optimizing for a scenario wher= e 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 wa= steland. It's certainly reasonable to expect that some individual users wou= ld 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 likel= y 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.

= 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 algor= ithm (or algorithm family).

The enormous difference is that Bitcoin users already=E2=80=8B op= ted into trusting that algorithm by using Bitcoin in the first place. Addin= g more algorithms means expanding the set of trusted algorithms, possibly a= gainst 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 discussio= n.


What are the thoughts here on SQIsign 2.0? My understanding is that it is 30X faster than the or= iginal 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 verificati= on time is 5.1 million ops (approximately 1.5 ms on a 3.4 GHz CPU). If ther= e were only one PQC signature algorithm to choose, this one seems to have g= ood trade offs (but it is still so new that I wouldn't feel comfortable tru= sting it alone and there not being any alternative to switch to).

I'm really not qualified to commen= t on this.

I don't think much thought has ever been given to the pro= blem before. ECDSA was the obvious choice in 2008. But newer, more efficien= t, 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 o= n Ed25519's security.

I s= trongly disagree with this. The security difference between ed25519 and sec= p256k1 ECDSA is marginal. They are both based on hardness of the ECDLP prob= lem. The secp256k1 curve has some unusual structure that may make it weaker= than generic curves, though this is a theoretical concern right now. On th= e other hand, the ed25519 curve is slightly smaller, which should net it ar= ound 1.2 bits less security (also marginal). In theory, ECDSA may have weak= nesses 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 th= ere was never a justification for adding ed25519. 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 that forces bearing that = cost.

= 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 th= e farm on a single PQC algorithm, or we can hedge by supporting multiple PQ= C algorithms. I don't envy the decision you and the other Bitcoin developer= s must make, I only hope that I can help make your decision easier by shari= ng my perspective.

This i= s 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 use it. By parti= cipating in this discussion, you too are part of the reasoning that will ul= timately 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.

Cheers,

-- 
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/VYtAQ= B0c0TAb_GQlnazB1OE9rtZDe8FsrAOg5YU7R6rZ8Etho2eg5gVJ0kxnwt9Qpln0FxTU3BJsuwKF= qjZOEz15HrF5UwoAxY-G8iIyXxU%3D%40wuille.net.
--b1=_h8Jjbo0FAOXFguxPN4zCryj4dI7NeNrf6QFkiuyQk--