From: "'Antoine Poinsot' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] In defense of a PQ output type
Date: Thu, 09 Apr 2026 18:58:14 +0000 [thread overview]
Message-ID: <0vqF88LoOnY4GiUB4vf-MdeZpTAtR70tokS3cLwt2DX0e6_fD1X_wyhPwWEdIdm6R88AULObIU08CWsb5QfeoaM5c4yXPqN5wHyCrqMCtfQ=@protonmail.com> (raw)
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.
next reply other threads:[~2026-04-09 19:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-09 18:58 'Antoine Poinsot' via Bitcoin Development Mailing List [this message]
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
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='0vqF88LoOnY4GiUB4vf-MdeZpTAtR70tokS3cLwt2DX0e6_fD1X_wyhPwWEdIdm6R88AULObIU08CWsb5QfeoaM5c4yXPqN5wHyCrqMCtfQ=@protonmail.com' \
--to=bitcoindev@googlegroups.com \
--cc=darosior@protonmail.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