From: Ethan Heilman <eth3rs@gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
Cc: Jonas Nick <jonasd.nick@gmail.com>, 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 15:35:20 -0500 [thread overview]
Message-ID: <CAEM=y+Uh63i0nYt4zcsPzpeNW2nwGhowCqQEHxLEE8EYMRY=sA@mail.gmail.com> (raw)
In-Reply-To: <ade8d7f0-8793-4971-a5bd-fc60e76f513a@mattcorallo.com>
[-- Attachment #1: Type: text/plain, Size: 8522 bytes --]
Replying to Waxwing, and Matt in this email
Waxwing:
> If supply and demand is king, why not just delete supply as much as
possible? No more mining?
I agree with you that a soft-fork that simply burns outputs to reduce
supply is unlikely to activate. I do agree with Matt's point given the
specific circumstances here.
Everyone would want soft-fork1. It freezes coins that would otherwise be
stolen with the promise to unfreeze them with a planned PQ ZKP proof of
seed phrase. Even the people whose coins would be frozen would want
soft-fork1 since it protects them. This makes it very likely that if the
threat of quantum theft is credible, soft-fork1 would activate and everyone
would be happy with this result (assuming it activates in time).
Now time passes, and the people whose coins are frozen want soft-fork2.
They feel they have waited long enough, but there is a problem. While
soft-fork1 was trivial to write, soft-fork2 requires a complex PQ ZKP that
will become consensus critical to Bitcoin. This is a complex task requiring
expertise. Will it actually get done? By whom?
Assume soft-fork2 actually gets built. Now it has to get activated.
Blocking a soft-fork is much easier than activating a soft-fork and this
will be a particularly contentious soft-fork.
Some will argue it is unfair that holders who did the right thing and
upgraded to secure outputs will be forced to on the consensus risks of a
dangerous soft-fork simply to unfreeze coins that the original owners
didn't even bother to secure. Others will just stall soft-fork2 by saying
it hasn't been tested enough or there isn't consensus. Making this worse,
miners are unlikely to want to increase supply. Getting miners to activate
soft-fork2 is much harder than soft-fork1.
Soft-fork1 activated because everyone was aligned. Soft-fork2 no longer has
that alignment and is much riskier.
"Aww shucks, we really support unfreezing these coins, but we the miners
just don't think the current iteration is ready for prime time, why don't
you put more work into it and try again in five years." - every five years
until the heat death of the universe.
Matt:
> I believe this is largely only possible either with an ethereum-style
"difficulty bomb" or simply doint it all in one go.
The do it all in one go approach avoids the incentive problem, but how will
this be built? How many cryptographers are willing to invest the years of
effort to create a soft fork that is unlikely to activate, all to protect
holders who can't be bothered to move to a safer output?
The most likely outcome is some kid just writes a simple soft-fork that
freezes all the insecure outputs, and miners activate it because they have
cover to reduce supply/pump the price. I'm not endorsing this course of
action, but it impacts my thinking on building PQ ZKP proof of seed phrase.
I ask myself why spend 5+ years on a PQ ZKP proof of seed phrase soft-fork
just to watch a low effort soft-fork annihilate all that work?
> No, P2TRv2 and P2MR are totally equivalent here. Because address reuse is
rampant, P2MR will *also* require an equivalent P2MR-disable-soft-fork. The
only material difference is the cost, and some small minority that doesn't
do heavy address reuse.
Wallets that encourage Schnorr key reuse with P2MR should be thrown out the
metaphorical airlock. Wallets claiming quantum safety must warn a user if
that user has exposed a Schnorr public key on the blockchain and make it
easy to move to a new address. There is UX work to be done on this problem,
but it is achievable and worthwhile.
On Thu, Feb 12, 2026 at 2:16 PM Matt Corallo <lf-lists@mattcorallo.com>
wrote:
>
>
> On 2/12/26 1:08 PM, Ethan Heilman wrote:
> > > Yep, we absolutely agree! I just don't see a reason to do P2MR over
> just utilizing P2TR (or
> > maybe P2TRv2).
> >
> > Here is my P2TRv2/ P2TRD vs P2MR analysis.
> >
> > Terms:
> > - P2TRv2-disable-soft-fork - refers to the soft-fork that disables key
> spend paths for P2TRv2
> > outputs, but does not disable key spend paths for other P2TR outputs.
> > - Q-day-long - The day at which long exposure attacks start happening.
> >
> > Set of outcomes for P2TRv2:
> > Future-A: Q-day-long happens and P2TRv2-disable-soft-fork is NOT
> activated. Funds are stolen from
> > P2TRv2 outputs, trust in Bitcoin declines.
> > Future-B: Q-day-long happens and P2TRv2-disable-soft-fork is activated.
> P2TRv2 outputs are protected
> > from quantum attacks.
> >
> > Set of outcomes for P2MR:
> > Future-C: Funds in P2MR are safe even if Q-day-long happens unexpectedly.
> >
> > The risk of Future-A will be priced into the value of Bitcoin. We can
> reduce Future-A risk by
> > activating P2TRv2-disable-soft-fork as early as possible. Activating
> P2TRv2-disable-soft-fork as
> > early as possible is equivalent to activating P2MR. Thus, might as well
> activate P2MR instead.
> >
> > Do we want to tell holders:
> > - Move to P2TRv2 and then trust us to activate the
> P2TRv2-disable-soft-fork in time
> > - Or move to P2MR, you'll be safe.
>
> No, P2TRv2 and P2MR are totally equivalent here. Because address reuse is
> rampant, P2MR will *also*
> require an equivalent P2MR-disable-soft-fork. The only material difference
> is the cost, and some
> small minority that doesn't do heavy address reuse.
>
> > > 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.
> >
> > Maybe in 2027, but what about 2028, 2029? If we see steady progress
> toward a CRQC the drumbeat will
> > become louder and louder and wallets will want to tell their users they
> are quantum-safe and secure
> > against classical attacks on ECC.
> >
> > The first parties to move over will likely be big holders willing to pay
> a trivial increase in fees
> > for security against existential tail risks.
>
> Right, so the first parties to move will be the ones we don't really care
> about (because they can
> just move quickly later anyway) :).
>
> > > 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"?
> >
> > soft-fork-1: Disables insecure key spend paths in P2TR. I don't have an
> opinion on the ethics of
> > this, but the incentives are aligned to make this happen (reduces
> supply).
> > soft-fork-2: ZKP proof of seed phase to allow people to safely spend
> from a disabled key spend path.
> > The incentives are aligned to oppose this soft-fork (increases supply).
> >
> > The incentives support soft-fork-1 happening, but soft-fork-2 not
> happening. I don't claim to
> > predict a future here, but the incentive issue here worries me.
>
> Fair. Given the ethics questions and the amount of pushback I have to
> imagine every effort *has* to
> be made to allow maximum wallets to retain coin ownership as otherwise the
> resulting Bitcoin has
> less value just because of seizure concerns. This all depends a ton on
> specifics, though - has it
> been 5 years since P2TRv2 was added? 10? 25? When did wallets start
> migrating in earnest? Did they
> even until it was too late?
>
> > Other questions:
> >
> > Soft-fork-1 must be designed so that soft-fork-2 is not a hard fork,
> that seems doable, has anyone
> > written up a plan for it?
>
> I believe this is largely only possible either with an ethereum-style
> "difficulty bomb" or simply
> doint it all in one go.
>
> > How big is this proposed PQ ZKP proof of seed phase? I've been assuming
> ~100kb per spend since we
> > have to use PQ ZKPs.
>
> Yes, I imagine quite large. Hence good to push migration along first. If
> migration is limited, I
> imagine there will be some desire to provide strong fee-discounts for
> these ZKPs, maybe also
> aggregating them in blocks.
>
> 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/CAEM%3Dy%2BUh63i0nYt4zcsPzpeNW2nwGhowCqQEHxLEE8EYMRY%3DsA%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 9585 bytes --]
next prev parent reply other threads:[~2026-02-13 16:22 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
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 [this message]
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='CAEM=y+Uh63i0nYt4zcsPzpeNW2nwGhowCqQEHxLEE8EYMRY=sA@mail.gmail.com' \
--to=eth3rs@gmail.com \
--cc=bitcoindev@googlegroups.com \
--cc=jonasd.nick@gmail.com \
--cc=lf-lists@mattcorallo.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