From: "'conduition' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
Cc: Antoine Poinsot <darosior@protonmail.com>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] In defense of a PQ output type
Date: Fri, 10 Apr 2026 17:03:21 +0000 [thread overview]
Message-ID: <6wBygQ_pK40ZpU_CMXfzIy-6LkthOmEh-xd2g9bwUl-f8w2K6G4rUWJEssE2zeJgxyipGe2GrFH9y_TUUI48asqfh7dhi9A2rl7NpWyFW1o=@proton.me> (raw)
In-Reply-To: <cba894e1-f830-4ad5-9498-09f04faaadf7@mattcorallo.com>
[-- Attachment #1.1: Type: text/plain, Size: 9759 bytes --]
Hi List,
I second Antoine's position. We can have two distinct fields of R&D proceeding concurrently:
1. Proactive: BIP360/P2MR; PQ signature opcodes; QSB & other scripting tricks
2. Retroactive: Freezing; Hourglass; Rescue protocols like BIP32 STARKs and commit/reveal
The two should be independent, because (1) need not affect inactive holders and legacy coins at all, whereas (2) necessarily does.
In my humble opinion, the proactive field (1) is the much more pressing issue. The sooner we settle on at least one address format and wallet structure for long-term hodling, the sooner PQ-vulnerable UTXOs can start migrating, and the fewer will be stolen or need rescue protocols later.
Though planning ahead for (2) is also important long-term. Laolu's recent development work building and benchmarking concrete BIP32 STARK proofs [1] is a great example. Through this, or a commit/reveal equivalent, maybe combined with an ownership proof used for non-BIP32 hashed addresses, I for one am confident we can catch a majority of exposed bitcoin in a safety net.
> 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
I think Antoine's point here is that if we introduce a PQC opcode to tapscript but choose NOT to deploy P2MR, and then encourage people to use that opcode in P2TR script leaves, then we are locking ourselves into the assumption that the community will later disable P2TR key-path spending - otherwise those addresses will be compromised by a CRQC and the PQC leaf script is useless.
> 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
I don't think anyone is suggesting deployment of an output type with mandatory hash-based signatures. That would be borderline unusable for anyone but large companies and wealthy elites.
Every decent proposal I've seen has suggested using PQC in tandem with ECC across multiple tapscript leaves, whether in some bastardized variant of P2TR, or in BIP360's P2MR.
My favorite idea is using hash-based sigs as a fallback escape hatch, because as a highly conservative field of cryptography, hash-based keys can be a fallback not just for ECC but for any future FancySig PQC algorithm we adopt in the future: lattice, isogeny, multivariate, whatevs. I posted an idea recently [2] for how to construct drop-in BIP32 replacement algorithms under this exact context.
regards,
conduition
[1]: https://groups.google.com/g/bitcoindev/c/Q06piCEJhkI
[2]: https://groups.google.com/g/bitcoindev/c/5tLKm8RsrZ0
On Thursday, April 9th, 2026 at 8:34 PM, Matt Corallo <lf-lists@mattcorallo.com> wrote:
>
>
> 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
> > 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.
>
> 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.
>
> > 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/cba894e1-f830-4ad5-9498-09f04faaadf7%40mattcorallo.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/6wBygQ_pK40ZpU_CMXfzIy-6LkthOmEh-xd2g9bwUl-f8w2K6G4rUWJEssE2zeJgxyipGe2GrFH9y_TUUI48asqfh7dhi9A2rl7NpWyFW1o%3D%40proton.me.
[-- Attachment #1.2: publickey - conduition@proton.me - 0x474891AD.asc --]
[-- Type: application/pgp-keys, Size: 649 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 343 bytes --]
next prev parent reply other threads:[~2026-04-10 17:47 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 ` [bitcoindev] " Olaoluwa Osuntokun
2026-04-09 22:46 ` Matt Corallo
2026-04-10 17:03 ` 'conduition' via Bitcoin Development Mailing List [this message]
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='6wBygQ_pK40ZpU_CMXfzIy-6LkthOmEh-xd2g9bwUl-f8w2K6G4rUWJEssE2zeJgxyipGe2GrFH9y_TUUI48asqfh7dhi9A2rl7NpWyFW1o=@proton.me' \
--to=bitcoindev@googlegroups.com \
--cc=conduition@proton.me \
--cc=darosior@protonmail.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