From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 12 Feb 2026 07:01:34 -0800 Received: from mail-oo1-f64.google.com ([209.85.161.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vqYCD-0006SK-Rj for bitcoindev@gnusha.org; Thu, 12 Feb 2026 07:01:34 -0800 Received: by mail-oo1-f64.google.com with SMTP id 006d021491bc7-672c40f3873sf14248202eaf.2 for ; Thu, 12 Feb 2026 07:01:33 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1770908487; cv=pass; d=google.com; s=arc-20240605; b=XcQeIr+XeYDjoGu0c/4kr556Tgd42jcW7du9IQCXR8etlhMu6x79tE2lZLqVA4tODI DZ3X14nw2qzx97of61XTsvphFVvcWhevmHjdYUEtitvFnS3lkXxi83gCH25MtDf09cw7 qKUjDiFEw6J4zH7twjh50mXuEXAsBQFdrPEqpKyPmRyKsrNc5jo1MSzdiXZMIY9B6kQN nUG099eHmnqIKfRGIMTLJn7Nuy9aXFwjPz3veRZjtZyCVlHrZXoReBIrySB5x8amYgBO KIk7s5w1eK55T/yCgaF0HoIgfGeFMTP6ZRW6MIsCCiKIVScwMjNc8d2QB2f1BCXmqytj qwTA== 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:content-transfer-encoding :in-reply-to:from:content-language:references:cc:to:subject :mime-version:date:message-id:sender:dkim-signature; bh=Q8+WQcQwpBc+0Txhl8EE+riKtZ2kmZoiHJ+U1IAC0OI=; fh=lOF69vZu4aK+BvMWTzVMe6NRHxksU0WLS6SWrvCaHt8=; b=R5mD1+TYIsKWKmKCeKeKrt8Yp9gNxdGolTNShoohzEwmsKvAq0iCqcj3szic7/B9lt HC1XoVPHoeAZ5X/Foz8ug1eYjucZHMPpkKKFPx/mgFywcypbEczQabVuzdfhSxgOWZfE mArhlEmhdDExdNP5Y8tevheFS9yG1Ssp0tl4umnwtAHGGYnrPZ1dqW9wvWADqUOq0Xhn 7qPZ/pWAX8MvCfDosMOIDSv5qdrBEKlIztQ4I8ayjs8uKpz7bHb0WYZxK4uX/mB0nR2u 5YJYL448Un+Sc1ccxfuJ975FGjGQpMCq/4b5Fk1ee8iMuGkjUIHXsH315J/N62E4itPh E//w==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1770906062 header.b=UHqyT5Im; dkim=pass header.i=@clients.mail.as397444.net header.s=1770906064 header.b=nzY5Daom; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 2620:6e:a000:1::99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1770908487; x=1771513287; 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:content-transfer-encoding:in-reply-to:from :content-language:references:cc:to:subject:mime-version:date :message-id:sender:from:to:cc:subject:date:message-id:reply-to; bh=Q8+WQcQwpBc+0Txhl8EE+riKtZ2kmZoiHJ+U1IAC0OI=; b=aXQDXv/ymq8Cb2irJOJ2NSa7VvQSXOjlXuQC8TRpLHtAXnHNFVkTE+DW1hdYax6e/c P/axfyPORjKb3C95s98YZsV7hCIkwV08bqSEPeriZQVRhdqYV7u87MBY/6jhFmRSuqBB lUVDW72zlsrwWVzECebxzpV1bCZ5aHDmCmw3HcTOQ4ukgB9FFXiOFJc8bs6RNOka71Hz 6kc7EjrGBpwhu0JHfqbZ6qHthIPrt7aqa8rDpipGtGmMSNbtkOKCoo9H1CUC8IDc+VV0 QSzDaIKmPc0tmPh6GlECGthtbKw27h2682qJ7furXi1Uqc1DJA5JSrh2DgJPiAmKy8H0 /UXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770908487; x=1771513287; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:in-reply-to:from :content-language:references:cc:to:subject:mime-version:date :message-id:x-beenthere:x-gm-message-state:sender:from:to:cc:subject :date:message-id:reply-to; bh=Q8+WQcQwpBc+0Txhl8EE+riKtZ2kmZoiHJ+U1IAC0OI=; b=IJ89Y+kEETKV9fdyOf7mSdUEJtC9n+Zk4rsFCdVJ/DpDca82xhfWvFyRAOYOvJpPtq roAp1o+FXOvfbKz9BakVa2XcI5cRluhV60+y3+oc0R0ZIJrCglneFeQO4qNB1bj5qYTr 53BaUL+DoirfzlI2jDPDuDLQ14GdU2s7HlbVsCIDN/hZFTwH7xQeV7A9rOqhETRGQsDq Ur0+OOqa1hUD8oeFx/HQJ2RnMgzLsrn8NLVAfh/+YHkJVMkh/P6GRw2R5xK23Ji9Vr4e 0VxAO4iP8sgA4yDeUyAiNdJo29n6CNuRpQUKh44hxu1PKzG7jPk39XaR6VtI6mVEA1Xo vljg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUmNEs7+oiclUP7ktSVmYjWjhDq/MGdn2xql+YXrZbPtwnl5JrGeQqgD0y8mSC/FbOetjRTKlGSO7As@gnusha.org X-Gm-Message-State: AOJu0YzWx2pRjiHNaXoLn7AElwRQ1dtAKFJ1bKWx2Ju8l2Up0LjHomlA hcpT7gYj1QCF+no2+Redm5kcadspN1QRDmtF31TYQxrUDKqbsmkX9Jho X-Received: by 2002:a05:6820:160e:b0:662:fe84:4775 with SMTP id 006d021491bc7-675dd829f36mr1017013eaf.56.1770908487403; Thu, 12 Feb 2026 07:01:27 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+HnA2bC9A2rOysGOICLgaBi7DsF3LJyeiuarstrFFDJng==" Received: by 2002:a05:6820:1689:b0:663:18f:35a0 with SMTP id 006d021491bc7-675d31113eals543932eaf.2.-pod-prod-08-us; Thu, 12 Feb 2026 07:01:21 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCWUkRHnkJeEpujasqW8wxIHyRikMVZyCDUSR/o4HGv4qgTxXjTwc5vatyNercRmmAGtu48S4K9f7dZl@googlegroups.com X-Received: by 2002:a05:6808:17a2:b0:45c:832a:cf43 with SMTP id 5614622812f47-4637fa94e60mr1091406b6e.14.1770908480907; Thu, 12 Feb 2026 07:01:20 -0800 (PST) Received: by 2002:a05:6808:a582:10b0:44f:fe66:38a2 with SMTP id 5614622812f47-462fc22be43msb6e; Thu, 12 Feb 2026 06:56:03 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCVhlSr5okxtyOiOwK7gKjbIhDD63gbBFmbllg+B/aMqYFYZieFFi4Q6pipwlDjq0btpiVCcehpBIJjh@googlegroups.com X-Received: by 2002:aa7:88cd:0:b0:81c:4a92:25a2 with SMTP id d2e1a72fcca58-824b300ec76mr2241012b3a.46.1770908162126; Thu, 12 Feb 2026 06:56:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1770908162; cv=none; d=google.com; s=arc-20240605; b=YewG3ziZ4B7MFUsQQCPJl/5/uukdL1AUuFI+Sg9VVVoFFsfcihLrMzJo6AlOQDkufg aIW5MVQ/7+uR9KbLfnBSZy1nNkLo2z0ku5HP+Y1ls269qKyKH2Hvv8t9Lj37ry9IFT/A R1TYq9R8yVXgVvIRF2aZQvxJOHiCp+HG9K88Ek9CtjHehfYAljIZ8EZ655b4KgOXghA4 M6gJU1vyQ1wNDIjrT41iMViBDYj0DqTEx6AYAe622Byk/M12R3Zx+rkVfncAbmnHOyYX UCJOAPJ37q7vy7S2K4M0NG2geQuOyqMpj5HL40JJhUfXsiM3B8H6raqINGai+rxixDk7 yJ0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:mime-version:date:message-id :dkim-signature:dkim-signature; bh=2L+DMXxxpy3zTxY07ZPKhXOxV2lxQUNPdcIlaAPN16k=; fh=S2qDizNoQti8YZADscR9tIHcHPuP+xTz24Htsxvm3BA=; b=gdp69opWXMyhSjHuurmeRJX1scYMFZgcpd1mdvDtz6Agh9PYaX/KigM76JuyPGFl/M EDd8aZTyo4aFUOsxfrglPdvTJKH9mzFJ6yIv6qNpfrjbp+H66DaWrGqNBJJ8OIhvD3pQ J8nS83feU8alvlStCBoqS/TV5E2eMyQ/fdrY4RbVFhITDNU2Bcp8ZXkM9+H05HRwUAEw 9Jn4IUB6a3om33QOcxC8WRyjls68L3A5Cb8CICS8kdDxNzJpNJvmeIMce07ChtWZRyns /8vIdoro0xrdnSMJEq4ufQI+MOQkGPPdEeXf1cMmfYVlJ17VkXco8i2NIs8kdwquZ96m TfLA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1770906062 header.b=UHqyT5Im; dkim=pass header.i=@clients.mail.as397444.net header.s=1770906064 header.b=nzY5Daom; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 2620:6e:a000:1::99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com Received: from mail.as397444.net (mail.as397444.net. [2620:6e:a000:1::99]) by gmr-mx.google.com with ESMTPS id d2e1a72fcca58-8249e3a2b6bsi194192b3a.1.2026.02.12.06.56.01 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Feb 2026 06:56:01 -0800 (PST) Received-SPF: pass (google.com: domain of lf-lists@mattcorallo.com designates 2620:6e:a000:1::99 as permitted sender) client-ip=2620:6e:a000:1::99; X-DKIM-Note: Keys used to sign are likely public at X-DKIM-Note: https://as397444.net/dkim/mattcorallo.com and X-DKIM-Note: https://as397444.net/dkim/clients.mail.as397444.net X-DKIM-Note: For more info, see https://as397444.net/dkim/ Received: by mail.as397444.net with esmtpsa (TLS1.3) (Exim) (envelope-from ) id 1vqY6q-00000008Fxk-2F7J; Thu, 12 Feb 2026 14:56:00 +0000 Message-ID: <1f0ebca9-2d23-44f9-8e6d-aaea99a832e3@mattcorallo.com> Date: Thu, 12 Feb 2026 09:55:59 -0500 MIME-Version: 1.0 Subject: Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms To: Ethan Heilman Cc: Jonas Nick , bitcoindev@googlegroups.com References: <22073a56-1cbf-4ba9-a2ea-46c621d4619c@mattcorallo.com> Content-Language: en-US From: Matt Corallo In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Original-Sender: lf-lists@mattcorallo.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1770906062 header.b=UHqyT5Im; dkim=pass header.i=@clients.mail.as397444.net header.s=1770906064 header.b=nzY5Daom; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 2620:6e:a000:1::99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.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.8 (/) On 2/11/26 5:57 PM, Ethan Heilman wrote: > > For what its worth I do not see a scenario where a decision ultimately= made by the market will=20 > pick the fork side with materially, say 5-10x higher, supply, over the si= de with lower supply... >=20 > Completely agree, the incentives favor lower supply. I wouldn't want to c= ount on it happening and=20 > even if it does happen the freeze fork might not freeze P2TR. According t= o the 2025 chaincode report=20 > [0] P2TR represents only 0.75% of total supply. I believe we're talking past each other, then. This was a side note - as Jo= nas mentioned it seems=20 reasonable that a P2TR-based QC signature validation opcode could come with= an on-chain signaling=20 bit (i.e. a "Taproot V2" that is functionally identical but indicates the p= resence of a QC signature=20 script path available). > > ~all wallets today use seedphrases, which could still be spent with a = ZK proof-of-seedphrase :). >=20 > I'm all for putting ZKPs in consensus, but it seems unlikely to me that i= t will happen. We just agreed that its highly likely that insecure spend paths are disable= d. I do not remotely see=20 how such an action could occur if the result is that a large number of coin= s are seized. The only=20 viable approach way for that is to allow seedphrase-based wallets to retain= access. > It is better=20 > to make Bitcoin safe than promise safety that requires a future hardfork. There is no hardfork required here. > This is especially true=20 > since as you point out lower supply is incentivized, so a soft fork that = freezes coins would be=20 > fighting an uphill battle. I'm confused by this comment - a soft fork that disables insecure spend pat= hs to avoid them being=20 stolen is likely going to have a very easy time, not "fight an uphill battl= e"? > > Hell, *any* PQ soft fork is going to see limited adoption in "consumer= wallets" until its=20 > urgent,=C2=A0hence why I think the community will be basically forced to = disable insecure spend paths and=20 > only > allow spends via ZK proof-of-seedphrase. But at least something that does= n't also 10x=20 > transaction=C2=A0costs might reasonably be adopted by default by wallets = that don't use seedphrases like=20 > Bitcoin Core. >=20 > I disagree. If we get P2MR and SLH_DSA/SHRINCS the wallets can use quantu= m-safe outputs (Schnorr OR=20 > PQ) with Schnorr as the default spend. The wallets can market themselves = as quantum safe. This flies in the face of the last 15 years of experience with Bitcoin wall= ets. Yea, it sounds=20 great, but we've got 15 years of experience showing that wallets only adapt= when they go out of=20 business/stop being maintained and get replaced with new wallets (which oft= en ship with the latest=20 technology). Worse, many bitcoiners (maybe rightfully, maybe not) entirely = write off the quantum=20 threat - all the more reason they will simply not adopt any changes. > The cost=20 > in transaction fees to a user is small, a 1 input P2MR transaction would = only be 37 bytes larger=20 > when compared with a 1 input P2TR transaction. Those 37 bytes are in the = witness, so the real cost=20 > is ~10 vbytes. Apologies, I had understood the P2MR proposal to only feature PQC-based sch= emes, rather than also=20 offering schnorr as an option, leading me to incorrectly conclude it would = be drastically more=20 expensive, rather than marginally so. Still, I think my point stands - in the face of many bitcoiners writing off= the quantum threat,=20 wallets aren't going to have a lot of incentive to adopt technologies that = make things marginally=20 more expensive. Worse, there's no real advantage here over just doing in the taproot key pa= th - because of address=20 reuse a wallet relying on P2MR + schnorr anyway will ~always have its publi= c key revealed so we=20 might as well continue relying on P2TR to save the 37 witness bytes and get= the same result (that=20 wallets can do something cheap with "just" a key derivation change and expl= icitly opt in to a future=20 soft fork which disables the then-insecure spend paths). > Yes, if Q-day happens, time passes and then quantum computers become powe= rful enough to perform=20 > short-exposure attacks, anyone needing to move their coins to an output h= ave=C2=A0to pay fees for an=20 > additional 8,000 bytes (SLH_DSA) or=C2=A0324 bytes (SHRINCs). This is sti= ll better than a PQ ZKP proof of=20 > the seed which would be between 20,000 to 120,000 bytes and more likely t= o have a security flaw than=20 > SLH_DSA. Yep, I'm not proposing at all that we do nothing because a ZKP of seedphras= e is an option, rather we=20 should add support for SHRINCS and encourage wallet adoption. But at the sa= me time we should=20 understand that we're incredibly unlikely to see the kind of adoption in ti= me to avoid the need to=20 do something like a ZKP of seedphrase when the time comes. This is also probably the least interesting point of contention, FWIW - thi= s is a decision for a=20 future bitcoin community, not a decision for us to make today. > If efficient quantum signatures or compression techniques are developed, = we can and should adopt=20 > them. If they are efficient enough, they can become the default. This pro= posal is designed to keep=20 > funds safe in the intermediate period while better techniques are develop= ed to cover the tail risk=20 > where Q-day happens before the technology we need to completely ready. Yep, we absolutely agree! I just don't see a reason to do P2MR over just ut= ilizing P2TR (or maybe=20 P2TRv2). > > No it doesn't - it requires a soft fork when the risk is imminent, but= it happening somewhat=20 > before that time is okay too. >=20 > We might wait too long and misjudge the risk and Q-day happens before the= soft fork activates? What=20 > happens if freeze fork is activated but then 3 years pass and it looks li= ke a CRQC isn't going to=20 > happen after all? Now people who had their coins frozen are pushing to un= do the soft fork. > This approach carries too much risk from uncertainty and it was "the plan= " it signles that Bitcoin =20 > leaving things up to chance that don't have to be left to chance. >=20 > Enabling people to opt in as early as possible enables the prudent to pro= tect themselves for very=20 > little effort and cost. Those people know their coins are safe and can st= ill use their coin as they=20 > did before. We agree. I believe your response is based on a misunderstanding of my argu= ment, hopefully clarified=20 above. > > I mean people can create invalid addresses today in plenty of ways. Ho= w is this unique? >=20 > P2TRD would be an address, which looks exactly like a 100% valid address = and which can be spend from=20 > like a valid address and hwoever at some future time, it may or may not, = become frozen. Sure, but this is still no different than any other P2TR script-path struct= ure - you have to test=20 things you use, even if you use them rarely, which is the entire point of t= he P2TR design :). Matt --=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/= 1f0ebca9-2d23-44f9-8e6d-aaea99a832e3%40mattcorallo.com.