From: Matt Corallo <lf-lists@mattcorallo.com>
To: Ethan Heilman <eth3rs@gmail.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:43:56 -0500 [thread overview]
Message-ID: <1e0842c2-a89b-44b6-a9d7-bc4a43636e9e@mattcorallo.com> (raw)
In-Reply-To: <CAEM=y+Uh63i0nYt4zcsPzpeNW2nwGhowCqQEHxLEE8EYMRY=sA@mail.gmail.com>
On 2/12/26 3:35 PM, Ethan Heilman wrote:
> 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?
I think this is all totally fair analysis, but I certainly hope the availability of decent PQ ZKPs
will improve over time and at least one PQ ZKP will be generally considered high quality by the time
a CRQC is on the immediate horizon. If you think that's unlikely, this is maybe something the
Bitcoin community should fund in the shorter term!
> > 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.
I agree! But also I try to be realistic. I mentioned in another email but a wallet reliably in the
top three app store results for "Bitcoin wallet" over the past few years (Trust wallet) started off
with fresh addresses regularly, then made it optional because it confused their users, then they
simply removed it entirely because no one ever turned it on.
> 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.
There has been some non-zero work to improve this situation for as long as I've been in Bitcoin, and
its only gotten worse and worse over the years. I wish I shared your optimism.
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/1e0842c2-a89b-44b6-a9d7-bc4a43636e9e%40mattcorallo.com.
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
2026-02-12 20:43 ` Matt Corallo [this message]
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=1e0842c2-a89b-44b6-a9d7-bc4a43636e9e@mattcorallo.com \
--to=lf-lists@mattcorallo.com \
--cc=bitcoindev@googlegroups.com \
--cc=eth3rs@gmail.com \
--cc=jonasd.nick@gmail.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