From: "'Antoine Poinsot' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: "dplusplus@gmail.com" <dplusplus@gmail.com>,
Matt Corallo <lf-lists@mattcorallo.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: Wed, 15 Apr 2026 18:15:16 +0000 [thread overview]
Message-ID: <b1Rnhsv35QTZwTeWM9R6Z9MGYw950zAXhs1QCuavxI64Y5CmSkYSXEP5bZgI3l1OY6V7PfBtBBAjXF1ACMznCg4VNrHJ1rMTD7qQM2hgtz8=@protonmail.com> (raw)
In-Reply-To: <0vqF88LoOnY4GiUB4vf-MdeZpTAtR70tokS3cLwt2DX0e6_fD1X_wyhPwWEdIdm6R88AULObIU08CWsb5QfeoaM5c4yXPqN5wHyCrqMCtfQ=@protonmail.com>
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..
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. 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?
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.
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.
Best,
Antoine
On Thursday, April 9th, 2026 at 3:06 PM, 'Antoine Poinsot' via Bitcoin Development Mailing List <bitcoindev@googlegroups.com> wrote:
> Many of us appear to be in favour of introducing post-quantum signatures to
> Bitcoin via a new Tapscript operation, conditioning the CRQC resistance on a
> future invalidation of Taproot key spends. I would like to offer an argument in
> favour of introducing such post-quantum signatures as a new output type instead,
> that does not depend on invalidating a spending path on existing outputs.
>
> First of all, it's important to clarify what we are trying to achieve. We need
> to accept that, by virtue of being faced with an uncertain existential threat to
> the network, there are scenarios, however unlikely, in which the network does
> not survive. Not all plausible futures are worth optimizing for. For instance,
> one in which PoW ends up broken only a few years after EC crypto, or one where
> the entire Bitcoin userbase *must* migrate within a handful of years.
>
> I think there are two futures worth optimizing for primarily:
> - a CRQC never materializes and users can continue benefiting from the
> properties of a Bitcoin network relying on classical cryptographic
> assumptions;
> - a CRQC materializes on a long enough timeframe that PQ signature schemes that
> maintain today's properties can be designed, vetted and adopted, and the vast
> majority of the userbase migrated.
>
> And because hope is not a strategy, it's important to also have a "break glass"
> emergency plan in case a CRQC emerges on a shorter (yet still reasonable)
> timeframe. I think the current proposals for hash-based PQ schemes fit this
> category. If they became the only safe option available, it would certainly make
> Bitcoin a lot less attractive. But having them around is good risk mitigation
> *regardless* of whether a CRQC emerges.
>
> It's often argued that a freeze will be necessary anyways, therefore we might as
> well disable the Taproot keyspend path simultaneously and simply introduce the
> PQ scheme today in Tapscript. I personally reject the premise, but more
> importantly i think we should separate the concerns of 1) making a PQ scheme
> available and 2) freezing vulnerable coins. Yet introducing a PQ scheme inside
> vulnerable Taproot outputs locks us onto the path of eventually freezing
> vulnerable coins, as it will inevitably turn users of the PQ scheme into
> supporters of a freeze.
>
> This approach would tie the availability of a PQ scheme to reaching consensus on
> a future freeze. Frankly, i do not believe the latter is achievable, let alone
> at this stage with so little evidence that a CRQC will materialize anytime soon.
> By contrast, there is a much stronger case for introducing a PQ scheme in the
> near term purely as a risk mitigation measure. Coupling the two decisions would
> necessarily delay the deployment of a PQ scheme, unnecessarily exacerbating
> risks whether or not CRQCs become a reality.
>
> Another drawback of the PQ output type approach is that it would make those
> outputs distinguishable from Taproot ones, which is suboptimal in the event that
> a CRQC never materializes. But i would argue that even in this case, the cost is
> minimal. The users most likely to adopt PQ outputs today (those securing large
> amounts of BTC with a small set of keys) already have vastly different usage
> patterns from Taproot users: they often reuse addresses and use legacy output
> types (and show little interest in upgrading).
>
> Best,
> Antoine Poinsot
>
> --
> 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/0vqF88LoOnY4GiUB4vf-MdeZpTAtR70tokS3cLwt2DX0e6_fD1X_wyhPwWEdIdm6R88AULObIU08CWsb5QfeoaM5c4yXPqN5wHyCrqMCtfQ%3D%40protonmail.com.
>
--
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/b1Rnhsv35QTZwTeWM9R6Z9MGYw950zAXhs1QCuavxI64Y5CmSkYSXEP5bZgI3l1OY6V7PfBtBBAjXF1ACMznCg4VNrHJ1rMTD7qQM2hgtz8%3D%40protonmail.com.
prev parent reply other threads:[~2026-04-15 18:47 UTC|newest]
Thread overview: 35+ 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 [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='b1Rnhsv35QTZwTeWM9R6Z9MGYw950zAXhs1QCuavxI64Y5CmSkYSXEP5bZgI3l1OY6V7PfBtBBAjXF1ACMznCg4VNrHJ1rMTD7qQM2hgtz8=@protonmail.com' \
--to=bitcoindev@googlegroups.com \
--cc=darosior@protonmail.com \
--cc=dplusplus@gmail.com \
--cc=laolu32@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