From: Matt Corallo <lf-lists@mattcorallo.com>
To: Antoine Poinsot <darosior@protonmail.com>,
"dplusplus@gmail.com" <dplusplus@gmail.com>,
Olaoluwa Osuntokun <laolu32@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] In defense of a PQ output type
Date: Sun, 19 Apr 2026 18:00:10 -0400 [thread overview]
Message-ID: <c7df3994-948b-4b3b-a8fa-c91e780cadfd@mattcorallo.com> (raw)
In-Reply-To: <b1Rnhsv35QTZwTeWM9R6Z9MGYw950zAXhs1QCuavxI64Y5CmSkYSXEP5bZgI3l1OY6V7PfBtBBAjXF1ACMznCg4VNrHJ1rMTD7qQM2hgtz8=@protonmail.com>
On 4/15/26 2:15 PM, Antoine Poinsot wrote:
> D++, Laolu, Matt,
>
> Thank you for your responses. Since you raise related points i'll reply in a
> single email.
>
> I think the disagreement boils down to what we are trying to achieve. The debate
> on output types is downstream of this, so i think it's worth pinning down the
> goal(s) first. My view is that we should mitigate short term risks to consensus
> in the event CRQCs never materialize, and minimize the amount of BTC (as well
> as UTxOs, ideally) at risk by the time they start being practical in the event
> they do. And, importantly, do so without creating more risks to Bitcoin's
> perceived value.
>
> This explicityly rules out some theoretically possible scenarios, which i
> believe can't be realistically addressed but are fortunately extremely unlikely.
>
> Another thing i'd like to address is how some replies appear to interpret my
> post as a defense of BIP 360. I think their approach of keeping Taproot's Merkle
> tree of BIP 342 Scripts is a fine design, but my argument applies to an output
> type that enables a hash-based PQ signature scheme, and preferably disables EC
> opcodes. BIP 360 as it stands does neither.
>
> Both D++ and Matt pointed out how my argument that introducing the PQ scheme in
> Taproot would create perverse incentives with regard to the later decision of
> freezing could be addressed by using a new Segwit version for PQ-Taproot, with a
> social expectation that the key path of such outputs may be disabled. Fair
> point, but i still think this is a weak guarantee. If usage of this new output
> type became popular for unrelated and unforeseen reasons, this could make
> disabling EC spending paths as murky as for regular Taproot.
>
> Another argument someone gave me in meatspace was that users of PQ schemes would
> turn into supporters of a freeze nonetheless, once they obtain the safety of a
> PQ output type for their own coins. That's plausible, but far from a certainty.
> I don't see much push for disabling the SHA1 operation today. And even if the
> share of BTC protected by EC operations was substantial enough to be a systemic
> risk, users of a PQ output type may prefer some amount of risk to the certain
> undermining of their asset's value proposition.
>
> Laolu, in response to the three futures i laid down that i think we should be
> optimising for, you pointed there is also a possible future in which there is
> classical advances in breaking the ECDLP problem. Sure, but i don't see why this
> should suddenly become a future we optimise for.
>
> Both Laolu and Matt pointed (in different languages) that a PQ output type is
> not mutually exclusive with a Taproot embedded version. It probably wouldn't
> hurt to also introduce a PQ scheme inside Taproot, unless we think that
> making the take-up of CRQC outputs publicly visible is a desirable property. But
> it's not clear to me that it would achieve much next to a PQ output type.
> Presumably, concerned large holders would favour the assurance of an
> actually CRQC-resistant output type, unless they believe the CRQC risk is lower
> than that of leaving their secure signing environment *and* they give credit to
> the social-signaling claim that such Taproot-v2 outputs will have their key path
> spend eventually be frozen. Same for laggards, why would they bear the cost of
> upgrading to a Taproot-v2 output if they assess the CRQC risk to be low enough?
> And once they believe it is high enough, why not use the CRQC-resistant output
> type instead? It seems to me that outside of newly created wallets, the case for
> a Taproot embedded PQ scheme is stronger *in place* of a PQ output type. If
> large holders have to use it in order to get access to a PQ spend path, then we
> can reasonably expect them to keep using the EC spend path until it gets
> disabled, thereby reducing their onchain footprint. However this alternative
> does weaken the risk mitigation(s), because one would have to believe the key
> spend path actually gets frozen eventually..
The problem is the entity who owns the coins is not the one making this decision. There is some
wallet developer who is going to decide what code to write based on their understanding of their
target market. Users are then going to decide which wallet to use based on recommendations from
their friends, random websites, or an app store. No one is carefully weighing at what point they
need to come back online and make a transaction before Q-day and then deciding which output type to use.
Instead, the best we can do is provide an option or two that we think gets the most coins migrated
"in time".
> Matt, you stated the (only) goal of a migration strategy should be to enable the
> maximum number of coins to be retained by their owner, and that this is only
> possible by disabling EC spend path(s) and (i guess hard-)forking a ZK-proof
> spend path for those fortunate users that happened to use a common key
> derivation standard. First of all, this is only true for those owners that are
> somehow unable to make a transaction until the advent of CRQCs, as any other
> owner could simply migrate to a PQ output type instead.
Or, more likely, unaware that they need to.
> And therefore, this is
> also incompatible with a higher-version-Taproot-output design that allows users
> to opt into a future EC spend path(s) freeze. Which are you arguing for?
Providing a shorter term alternative like a higher-version-Taproot-output blunts the cost of later
migration logic like ZK-proof-of-BIP-32.
> More importantly, i think your goal statement goes to the heart of the issue.
> Maximizing the amount of coins to be retained by their owner is of course
> desirable, but it can't be the only goal. Especially if it comes at the cost of
> consensus changes that risk burning other users' coins.
In this case, we simply disagree. In the face of coins which can be stolen by a CRQC, the best
outcome is to maximize the probability that their true owner retains control. That means, yes,
having some probability that the coins are burned. I'm unaware of a way to do so otherwise.
> Finally, Matt you also asserted that a PQ output type alone is not a migration
> strategy since it would not achieve much. I think that if you spell out the
> argument behind this statement, the case is actually weaker than it seems. The
> burden associated with using a hash-based PQ scheme would certainly slow down
> adoption for those users that have less at stake, or whose usage patterns would
> be particularly impacted. But it's only natural that holders with different
> stakes and risk profiles make different risk assessments. Each may migrate to
> the new output type as the assurance it provides comes to outweigh its
> associated costs.
See above. I think this is somewhat simplistic reasoning about how decisions around address formats
are actually made.
But I will say, I've somewhat come around to the idea of a PQ-only output type in conjunction with
something more akin to flagged-P2TR. The former provides an option for those who think that there
will be a bitcoin if only large, conservative holders are able to retain their coins in the face of
a surprise CRQC, the latter provides an option that is cheap, retains existing implementation as
much as possible, and provides a way to get PQC pubkeys attached to outputs in a measurable way to
inform a later Bitcoin community of whether a ZK recovery scheme is viable and required.
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/c7df3994-948b-4b3b-a8fa-c91e780cadfd%40mattcorallo.com.
prev parent reply other threads:[~2026-04-19 22:08 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-09 18:58 'Antoine Poinsot' via Bitcoin Development Mailing List
2026-04-09 20:31 ` [bitcoindev] " Dplusplus
2026-04-09 21:17 ` [bitcoindev] " Olaoluwa Osuntokun
2026-04-09 22:46 ` Matt Corallo
2026-04-10 17:03 ` 'conduition' via Bitcoin Development Mailing List
2026-04-10 20:33 ` Matt Corallo
2026-04-11 0:20 ` Ethan Heilman
2026-04-11 1:04 ` 'Hayashi' via Bitcoin Development Mailing List
2026-04-11 1:25 ` Antoine Riard
2026-04-13 14:21 ` 'Hayashi' via Bitcoin Development Mailing List
2026-04-15 19:05 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2026-04-15 19:14 ` Erik Aronesty
2026-04-15 20:16 ` محمد الوصابي
2026-04-13 14:02 ` Matt Corallo
2026-04-14 1:45 ` 'conduition' via Bitcoin Development Mailing List
2026-04-14 12:36 ` Thomas Suau
2026-04-14 14:51 ` 'conduition' via Bitcoin Development Mailing List
2026-04-14 15:50 ` thomas suau
2026-04-14 19:09 ` 'conduition' via Bitcoin Development Mailing List
2026-04-14 15:33 ` Matt Corallo
2026-04-14 18:56 ` 'conduition' via Bitcoin Development Mailing List
2026-04-14 20:04 ` Matt Corallo
2026-04-15 11:02 ` Matt Corallo
2026-04-15 14:36 ` Ethan Heilman
2026-04-15 15:17 ` Matt Corallo
2026-04-15 16:01 ` Ethan Heilman
2026-04-15 16:03 ` Matt Corallo
2026-04-15 16:26 ` Ethan Heilman
2026-04-15 16:36 ` Matt Corallo
2026-04-15 20:19 ` Anthony Towns
2026-04-15 21:50 ` Matt Corallo
2026-04-15 23:30 ` Anthony Towns
2026-04-16 11:15 ` Matt Corallo
2026-04-16 11:19 ` Garlo Nicon
2026-04-15 18:15 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2026-04-19 22:00 ` Matt Corallo [this message]
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=c7df3994-948b-4b3b-a8fa-c91e780cadfd@mattcorallo.com \
--to=lf-lists@mattcorallo.com \
--cc=bitcoindev@googlegroups.com \
--cc=darosior@protonmail.com \
--cc=dplusplus@gmail.com \
--cc=laolu32@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