From: Alex <alexhultman@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
Date: Thu, 12 Feb 2026 07:35:30 -0800 (PST) [thread overview]
Message-ID: <dd2fcc40-cedc-48ae-b23d-6029f678c184n@googlegroups.com> (raw)
In-Reply-To: <1f0ebca9-2d23-44f9-8e6d-aaea99a832e3@mattcorallo.com>
[-- Attachment #1.1: Type: text/plain, Size: 8679 bytes --]
> wallets aren't going to have a lot of incentive to adopt technologies
that make things marginally
more expensive.
This claim is not rooted in reality. We literally just now saw Trezor
market their Safe 7 as Quantum Ready and they had a major ad campaign
specifically for this. There is major incentive for wallets to "sell" the
quantum threat as a problem to fix, and therefore sell more wallets or
claim compliance to gain market share. The quantum threat is mainstream.
Retail knows about it, talks about it all the time.
> many bitcoiners writing off the quantum threat
Yes because psychologically, the most successful Bitcoiners are those who
never reacted to any FUD and therefore never sold. And so they are
essentially naturally selected by their history of never reacting to FUD.
We've basically evolved the most non-reactant people and so obviously they
are not going to react to the quantum threat because why would they change
their strategy of never reacting if it worked so well so far?
torsdag 12 februari 2026 kl. 16:01:27 UTC+1 skrev Matt Corallo:
>
>
> 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
> > pick the fork side with materially, say 5-10x higher, supply, over the
> side with lower supply...
> >
> > Completely agree, the incentives favor lower supply. I wouldn't want to
> count on it happening and
> > even if it does happen the freeze fork might not freeze P2TR. According
> to the 2025 chaincode report
> > [0] P2TR represents only 0.75% of total supply.
>
> I believe we're talking past each other, then. This was a side note - as
> Jonas mentioned it seems
> reasonable that a P2TR-based QC signature validation opcode could come
> with an on-chain signaling
> bit (i.e. a "Taproot V2" that is functionally identical but indicates the
> presence of a QC signature
> script path available).
>
> > > ~all wallets today use seedphrases, which could still be spent with a
> ZK proof-of-seedphrase :).
> >
> > I'm all for putting ZKPs in consensus, but it seems unlikely to me that
> it will happen.
>
> We just agreed that its highly likely that insecure spend paths are
> disabled. I do not remotely see
> how such an action could occur if the result is that a large number of
> coins are seized. The only
> viable approach way for that is to allow seedphrase-based wallets to
> retain access.
>
> > It is better
> > to make Bitcoin safe than promise safety that requires a future hardfork.
>
> There is no hardfork required here.
>
> > This is especially true
> > since as you point out lower supply is incentivized, so a soft fork that
> freezes coins would be
> > fighting an uphill battle.
>
> I'm confused by this comment - a soft fork that disables insecure spend
> paths to avoid them being
> stolen is likely going to have a very easy time, not "fight an uphill
> battle"?
>
> > > Hell, *any* PQ soft fork is going to see limited adoption in "consumer
> wallets" until its
> > urgent, hence why I think the community will be basically forced to
> disable insecure spend paths and
> > only
> > allow spends via ZK proof-of-seedphrase. But at least something that
> doesn't also 10x
> > transaction costs might reasonably be adopted by default by wallets that
> don't use seedphrases like
> > Bitcoin Core.
> >
> > I disagree. If we get P2MR and SLH_DSA/SHRINCS the wallets can use
> quantum-safe outputs (Schnorr OR
> > 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
> wallets. Yea, it sounds
> great, but we've got 15 years of experience showing that wallets only
> adapt when they go out of
> business/stop being maintained and get replaced with new wallets (which
> often ship with the latest
> technology). Worse, many bitcoiners (maybe rightfully, maybe not) entirely
> write off the quantum
> threat - all the more reason they will simply not adopt any changes.
>
> > The cost
> > in transaction fees to a user is small, a 1 input P2MR transaction would
> only be 37 bytes larger
> > when compared with a 1 input P2TR transaction. Those 37 bytes are in the
> witness, so the real cost
> > is ~10 vbytes.
>
> Apologies, I had understood the P2MR proposal to only feature PQC-based
> schemes, rather than also
> offering schnorr as an option, leading me to incorrectly conclude it would
> be drastically more
> expensive, rather than marginally so.
>
> Still, I think my point stands - in the face of many bitcoiners writing
> off the quantum threat,
> wallets aren't going to have a lot of incentive to adopt technologies that
> make things marginally
> more expensive.
>
> Worse, there's no real advantage here over just doing in the taproot key
> path - because of address
> reuse a wallet relying on P2MR + schnorr anyway will ~always have its
> public key revealed so we
> might as well continue relying on P2TR to save the 37 witness bytes and
> get the same result (that
> wallets can do something cheap with "just" a key derivation change and
> explicitly opt in to a future
> soft fork which disables the then-insecure spend paths).
>
> > Yes, if Q-day happens, time passes and then quantum computers become
> powerful enough to perform
> > short-exposure attacks, anyone needing to move their coins to an output
> have to pay fees for an
> > additional 8,000 bytes (SLH_DSA) or 324 bytes (SHRINCs). This is still
> better than a PQ ZKP proof of
> > the seed which would be between 20,000 to 120,000 bytes and more likely
> to have a security flaw than
> > SLH_DSA.
>
> Yep, I'm not proposing at all that we do nothing because a ZKP of
> seedphrase is an option, rather we
> should add support for SHRINCS and encourage wallet adoption. But at the
> same time we should
> understand that we're incredibly unlikely to see the kind of adoption in
> time to avoid the need to
> do something like a ZKP of seedphrase when the time comes.
>
> This is also probably the least interesting point of contention, FWIW -
> this is a decision for a
> 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
> > them. If they are efficient enough, they can become the default. This
> proposal is designed to keep
> > funds safe in the intermediate period while better techniques are
> developed to cover the tail risk
> > 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
> utilizing P2TR (or maybe
> P2TRv2).
>
> > > No it doesn't - it requires a soft fork when the risk is imminent, but
> it happening somewhat
> > before that time is okay too.
> >
> > We might wait too long and misjudge the risk and Q-day happens before
> the soft fork activates? What
> > happens if freeze fork is activated but then 3 years pass and it looks
> like a CRQC isn't going to
> > happen after all? Now people who had their coins frozen are pushing to
> undo the soft fork.
>
> > This approach carries too much risk from uncertainty and it was "the
> plan" it signles that Bitcoin
> > leaving things up to chance that don't have to be left to chance.
> >
> > Enabling people to opt in as early as possible enables the prudent to
> protect themselves for very
> > little effort and cost. Those people know their coins are safe and can
> still use their coin as they
> > did before.
>
> We agree. I believe your response is based on a misunderstanding of my
> argument, hopefully clarified
> above.
>
> > > I mean people can create invalid addresses today in plenty of ways.
> How is this unique?
> >
> > P2TRD would be an address, which looks exactly like a 100% valid address
> and which can be spend from
> > 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
> structure - you have to test
> things you use, even if you use them rarely, which is the entire point of
> the P2TR design :).
>
> Matt
>
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/dd2fcc40-cedc-48ae-b23d-6029f678c184n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 9707 bytes --]
next prev parent reply other threads:[~2026-02-12 18:41 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-09 14:20 Ethan Heilman
2026-02-10 8:53 ` Jonas Nick
2026-02-10 16:44 ` Ethan Heilman
[not found] ` <CAJowKg+WJLAJoMhyhVfkC9OSdks5jBieDWty9ce-Qju-84URFA@mail.gmail.com>
2026-02-10 23:13 ` Ethan Heilman
2026-02-11 0:19 ` Erik Aronesty
2026-02-11 2:40 ` Ethan Heilman
2026-02-11 7:25 ` Erik Aronesty
2026-02-11 16:37 ` Ethan Heilman
2026-02-17 4:13 ` 'conduition' via Bitcoin Development Mailing List
2026-02-17 7:39 ` 'conduition' via Bitcoin Development Mailing List
2026-02-19 14:35 ` Garlo Nicon
2026-02-20 1:41 ` Alex
2026-02-20 18:48 ` Erik Aronesty
2026-02-23 14:00 ` 'conduition' via Bitcoin Development Mailing List
2026-02-23 19:08 ` Erik Aronesty
2026-02-23 21:42 ` Ethan Heilman
2026-02-24 0:12 ` Alex
2026-02-25 10:43 ` Javier Mateos
2026-02-26 13:24 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List
2026-02-26 15:51 ` Matt Corallo
2026-02-27 15:18 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List
2026-02-27 19:31 ` 'conduition' via Bitcoin Development Mailing List
2026-03-01 12:24 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List
2026-03-01 21:28 ` Alex
2026-02-11 18:53 ` Matt Corallo
2026-02-11 22:57 ` Ethan Heilman
2026-02-12 14:55 ` Matt Corallo
2026-02-12 15:35 ` Alex [this message]
2026-02-12 19:20 ` Matt Corallo
2026-02-12 18:08 ` Ethan Heilman
2026-02-12 19:13 ` Matt Corallo
2026-02-12 20:35 ` Ethan Heilman
2026-02-12 20:43 ` Matt Corallo
2026-02-12 15:13 ` Alex
2026-02-12 19:16 ` Matt Corallo
2026-02-12 15:36 ` waxwing/ AdamISZ
2026-02-12 19:35 ` Matt Corallo
2026-02-12 19:43 ` Matt Corallo
2026-02-14 12:39 ` waxwing/ AdamISZ
2026-02-15 12:12 ` Matt Corallo
2026-02-10 21:51 ` 'Brandon Black' via Bitcoin Development Mailing List
2026-02-10 22:19 ` Ethan Heilman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=dd2fcc40-cedc-48ae-b23d-6029f678c184n@googlegroups.com \
--to=alexhultman@gmail.com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox