From: Olaoluwa Osuntokun <laolu32@gmail.com>
To: Antoine Poinsot <darosior@protonmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] In defense of a PQ output type
Date: Thu, 9 Apr 2026 14:17:20 -0700 [thread overview]
Message-ID: <CAO3Pvs8zjQr+n2OnJ1J3M++Otx73YNrJW-g9ZCJdOx=q7aixKA@mail.gmail.com> (raw)
In-Reply-To: <0vqF88LoOnY4GiUB4vf-MdeZpTAtR70tokS3cLwt2DX0e6_fD1X_wyhPwWEdIdm6R88AULObIU08CWsb5QfeoaM5c4yXPqN5wHyCrqMCtfQ=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 7968 bytes --]
Hi Antoine,
TL;DR: "¿Por qué no los dos?"
IMO it isn't really either or re a new PQ output type vs disabling certain
vulnerable spending types with various flavors of a pq secure escape hatch.
Adding a new PQ op codes and/or output types would be a precautionary soft
fork
(ppl to migrate at their leisure), while disabling certain spending paths
w/ an
escape hatch would be an emergency softfork.
Even in the face of the emergency soft fork, PQ safe signature types are
still
needed, otherwise you don't have a "safe" place to sweep those vulnerable
outputs into. Also note that it's possible to create safe escape hatches for
non-Taproot output types as well (assuming a hash function was used to
derive
the private scalar from a seed, commonly BIP-32).
IMO Taproot (in addition to a new type ofc), is still an attractive target
as
there's already so much wallet+signing infrastructure built up around it. So
far the newly proposed output type variants seem to keep much of the bsae of
Taproot which is great, as that'll speed up adoption, but we've already seen
first hand how long it can take a new output type to be adopted.
> I think there are two futures worth optimizing for primarily:
There's also a third future in which there's some _classical_ advancement in
the ECDLP problem, that prompts a move away from EC crypto even without an
actual quantum attacker.
> i think we should separate the concerns of 1) making a PQ scheme available
> and 2) freezing vulnerable coins 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.
I totally agree that a precautionary fork and an emergency for need not be
tied
together. The technical question of which signature scheme(s) to add is much
more straight forward than the politically tinged question of which output
types/utxos to disable spending for.
IMO an important reason to have background development on the "PQ rescue"
fork
details is that invariably there'll be laggards in the adoption of a PQ
output
type even if it was made available _today_.
Consider how many exchanges and custodians rely on variants of HSMs for
secure
signing. If we look at popular offerings like AWS CloudHSM, they now have
support for secp256k1 [1][2], but AFAICT, that was added only around 2019
or so
(can anyone confirm?). Taproot has been active for many years now, but
because
it uses a bespoke signature type (on a relative basis), major providers like
AWS don't have _direct_ support (tho one could prob emulate it with a Nitro
Enclave).
Even if these popular HSM providers had support today (IIRC AWS KMS added
ML-DSA support last year, but not SLH-DSA yet) for the NIST PQ schemes, it
would likely be some time until they added whichever variant(s) (eg:
composite
hash based, hash based with non-standard params for smaller sigs, lattice
based
variants that support BIP-32 hardened derivation) that Bitcoin selects in
the
end.
-- Laolu
[1]:
https://docs.aws.amazon.com/cloudhsm/latest/userguide/pkcs11-key-types.html
[2]:
https://docs.aws.amazon.com/kms/latest/developerguide/symm-asymm-choose-key-spec.html
On Thu, Apr 9, 2026 at 12: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/CAO3Pvs8zjQr%2Bn2OnJ1J3M%2B%2BOtx73YNrJW-g9ZCJdOx%3Dq7aixKA%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 9339 bytes --]
next prev parent reply other threads:[~2026-04-09 21:24 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
2026-04-09 20:31 ` [bitcoindev] " Dplusplus
2026-04-09 21:17 ` Olaoluwa Osuntokun [this message]
2026-04-09 22:46 ` [bitcoindev] " 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='CAO3Pvs8zjQr+n2OnJ1J3M++Otx73YNrJW-g9ZCJdOx=q7aixKA@mail.gmail.com' \
--to=laolu32@gmail.com \
--cc=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