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: Wed, 11 Feb 2026 17:57:09 -0500 [thread overview]
Message-ID: <CAEM=y+WRk6JU2xNdh6YYQE9VmkH1kv-CwBSYBxu0C0WocyKwNQ@mail.gmail.com> (raw)
In-Reply-To: <22073a56-1cbf-4ba9-a2ea-46c621d4619c@mattcorallo.com>
[-- Attachment #1: Type: text/plain, Size: 8582 bytes --]
> 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.
> ~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. It is better to make Bitcoin safe than promise safety that
requires a future hardfork. 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.
> 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. 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.
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.
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.
> 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.
> 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.
[0]: https://chaincode.com/bitcoin-post-quantum.pdf
On Wed, Feb 11, 2026 at 1:53 PM Matt Corallo <lf-lists@mattcorallo.com>
wrote:
>
>
> On 2/10/26 11:44 AM, Ethan Heilman wrote:
> > > If Bitcoin disables Taproot key path spends before Q-day, then doing
> this via Taproot instead of
> > BIP 360 would be preferable.
> >
> > I worry about making the transition to quantum-safe outputs depend on a
> contentious debate over a
> > confiscatory soft fork. Uncertainty over whether the soft fork would be
> released and if released
> > would be activated means that wallets and custodians are unlikely to
> have invested the resources
> > into upgrading to support script only P2TR.
>
> 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...supply
> and demand is king, especially with the "confiscatory" nature is basically
> nil as ~all wallets today
> use seedphrases, which could still be spent with a ZK proof-of-seedphrase
> :).
>
> > The benefit of BIP 360's P2MR (Pay-to-Merkle-Root) + SLH_DSA is that it
> avoids this controversy by
> > being opt-in and non-confiscatory. This also means that BIP 360 +
> SLH_DSA is likely to activated
> > early, allowing wallets and custodians ample time to build support after
> activation.
>
> The drawback being that it will see zero relevant adoption until its way
> too late.
>
> The only entities that would reasonably adopt something like this are
> large custodians, who aren't
> worth worrying about as they'll easily migrate all their coins over the
> course of a few days or
> weeks in an emergency scenario, and highly specialty wallets. The point of
> any PQ soft fork today is
> if it can actually drive wallets to start making progress on PQ
> deployment. A new address type that
> is 10x more expensive to transact with is going to see ~zero adoption in
> "consumer wallets" until
> its urgent, at which point its obviously way, way too late.
>
> 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.
>
> > > We could define a new SegWit version that is a copy of Taproot. The
> new version number simply
> > signals that the owner consents to a future deactivation of key path
> spends. Unlike BIP 360, this
> > approach would still require actually disabling the key path before
> Q-day, but it is not
> > confiscatory and allows using Taproot's benefits until then (with
> a privacy hit from having two
> > versions of Taproot in parallel).
> >
> > Let's call this P2TRD (Pay-to-Tap-Root-Disablable). BIP 360 evolved from
> this P2TRD idea, to
> > minimize the following hazards in P2TRD.
> >
> > 1. P2TRD requires a soft fork that depends on accurately predicting
> Q-day or when EC Schnorr is
> > classically broken. We must not only predict Q-day but also convince the
> community that the
> > prediction is correct. If we mess up the timing, Bitcoin is
> significantly harmed. This means that
> > people will constantly be yelling that we are messing up the timing. It
> will make quantum FUD worse
> > not better.
>
> No it doesn't - it requires a soft fork when the risk is imminent, but it
> happening somewhat before
> that time is okay too.
>
> > 2. P2TRD (Pay-to-Tap-Root-Disablable) to be non-confiscatory users must
> create a script spend that
> > replicates their key spend, But users and wallets are likely to screw
> this up and not create script
> > spends. The is no way to see if a wallet is actually creating the script
> spend on the blockchain.
>
> I mean people can create invalid addresses today in plenty of ways. How is
> this unique?
>
> > 3. To be safe from long-exposure attacks P2TRD can't use the same public
> key for the script spend as
> > the key spend. Since wallets will prefer the key spend to the script
> spend, a user might not realize
> > if they lost the keying material for their script spend until after
> activation.
>
> It would almost certainly just be a key derived from the seedphrase via
> another hash function, so
> there's no real risk of this.
>
> 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%2BWRk6JU2xNdh6YYQE9VmkH1kv-CwBSYBxu0C0WocyKwNQ%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 9599 bytes --]
next prev parent reply other threads:[~2026-02-11 23:14 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 [this message]
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
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+WRk6JU2xNdh6YYQE9VmkH1kv-CwBSYBxu0C0WocyKwNQ@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