In defense of a PQ output type

[Antoine Poinsot]

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

[Dplusplus]

Antoine,

Yes, +1 on decoupling the PQ signature discussion from the "freeze" discussion.

As one example of what this could look like, P2Q (https://github.com/casey/bips/blob/280fb529b27949b42721bfbf5f255e67b9a1103b/bip-p2q.md) formalizes that decoupling. P2Q is a new SegWit version (v3) with spending rules identical to Taproot today, but with an explicit roadmap: a future soft fork could disable key-path spending for v3 outputs only, without touching existing P2TR UTXOs.

Users who send to a P2Q address are deliberately opting in to that future possibility. The cryptographic decision and the social decision about unmigrated coins become cleanly separable. It also preserves Schnorr's benefits (FROST, MuSig2, Taproot channels, etc.) for everyone who wants to continue using them in the meantime, while P2MR does not.

The part that feels strange to me is the assumption I keep seeing that SegWit v1 key-path spending will "simply" be disabled in a future soft fork. That bakes confiscation into the roadmap without ever asking users to opt in. Whether "freeze" ultimately wins is a decision for the market to make on its own timeline.

D++

[Olaoluwa Osuntokun]

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

--
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+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/0vqF88LoOnY4GiUB4vf-MdeZpTAtR70tokS3cLwt2DX0e6_fD1X_wyhPwWEdIdm6R88AULObIU08CWsb5QfeoaM5c4yXPqN5wHyCrqMCtfQ%3D%40protonmail.com.

[Matt Corallo]

On 4/9/26 2:58 PM, 'Antoine Poinsot' via Bitcoin Development Mailing List 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

You've missed the much-more-important thing that cannot be extricated from disabling insecure spend
paths - the ability to recover from a seedphrase. In any world where a CRQC exists, whether it is
next year or a century from now, there will be a million or two bitcoin in lost-key-wallets and a
nontrivial amount in wallets people haven't touched in ten years but still have keys for. Given a
goal of any migration strategy should be to enable the absolute maximum number of coins to be
retained by their owners (I think this is basically the *only* goal?), enabling seedphrase proof
recovery is pretty critical. Sadly the only way that can be done is through disabling insecure spend
proofs.

But you've also confused unrelated concerns here - whether a hash-based signature is added as a
tapscript opcode or not is not strictly tied to whether a new output type is created. If BIP 360 is
the way bitcoin goes, it *still* needs a new hash-based opcode in tapscript. Maybe more
interestingly, a new taproot "version" could be added which has identical semantics to today's
taproot but signals through an alternative version number (or maybe there's a cleverer way to encode
a bit somewhere that we should prefer) that a PQC pubkey exist in a taproot leaf somewhere so the
insecure spend path should be disabled.

> 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.

Adding a PQ output type which no one will use (eg one where use of the hash-based signature is
mandatory, which drives fees up hugely and has all the drawbacks you mention) is not a risk
mitigation strategy - it does not materially allow for any migration and doesn't accomplish much of
anything. But as mentioned above I do not see why any addition of hash based signatures to tapscript
should require any kind of community consensus on future disablement of insecure spend paths - not
only is it a likely prerequisite for an alternative output type, but its also (obviously?) not
possible to have any kind of "consensus" on what the future bitcoin community will do. Thus it would
be rather impossible to do *anything* if that were a requirement.