From: "'Hayashi' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] In defense of a PQ output type
Date: Mon, 13 Apr 2026 07:21:51 -0700 (PDT) [thread overview]
Message-ID: <a1aab08b-bea4-4dd9-a289-59994375849fn@googlegroups.com> (raw)
In-Reply-To: <459bd81c-584f-4adf-9112-bb733d381c99n@googlegroups.com>
[-- Attachment #1.1: Type: text/plain, Size: 8839 bytes --]
Hi Antonie,
>I'm +1 on disentangling the introduction of a PQ safe scheme from
>the more fuzzy idea of freezing coins based on output types.
I agree with separating them, but I think we should not shy away from
whether to deprecate EC signatures or not.
>Even the idea of "freezing" coins, the goal of why is still unclear.
>It sounds the motivations are blurred between ensuring coins are
>staying in the hands of their legitimate owners, a goal I can share
>but I don't see how freezing help here
By disabling insecure signature, recovery with ZKP of xpriv will be
possible even from pubkey-exposed addresses (some may not call it "freeze"
though).
Address reuse is common and sharing xpub is also common (I cannot blame
them because it is "public" key).
Putting aside P2PK, a combination of deprecating EC signatures and
activation of ZKP recovery will, I believe, result in maximum ownership
preservation in the face of CRQC.
Hayashi
2026年4月11日土曜日 9:28:27 UTC+8 Antoine Riard:
Hi,
Thanks for rolling up the ball forward on this topic.
I'm +1 on disentangling the introduction of a PQ safe scheme from
the more fuzzy idea of freezing coins based on output types.
Even the idea of "freezing" coins, the goal of why is still unclear.
It sounds the motivations are blurred between ensuring coins are
staying in the hands of their legitimate owners, a goal I can share
but I don't see how freezing help here, from the more loose idea of
ensuring there is no crash in the bitcoin price vs fiat in the face
of CQRC-enabled attacks, which sounds to me a pandora box.
Even in this eventuality, if there is a general concern on the network
disruptions that might be induced by CRQC attacks (e.g chain instability
due to reorgs by competing CRQC attackers), I believe there are still
intermediary technical solutions, e.g rate-limiting the number of output
types that can be spent by difficulty periods to minimize the risks of
disruptions, while not technically confiscating anyone coin.
Back to introducing a PQ safe scheme, I don't think in this thread
the question is raised to enable to secure one's coin under double
classic cryptogrraphic assumption and PQ assumption, i.e "hybrid"
security (more for the risk of a cryptanalysis break of any PQ safe
scheme that would be introduced at the consensus-level). It might
more a real engineering burden, though I believe it's giving more
flexibility for technically savy bitcoin users to secure one's stack.
Anyway, I think it's good to have a scheme ready early on given
the development cycle to have stuff available on HW wallets and
HSMs. E.g BIP32 support was added in 2018 on Gemalto's HSM i.e a
mere 6 years after the standard introduction (which is not that
bad given that blockchain were recents actors in the hardware
industry at the time).
Best,
Antoine
OTS hash: 6d7c2f5ab01bcdda4ec27d4c21198a9b13ce1dfd138c4a2e6dfaedee9458f6c0
Le Saturday, April 11, 2026 à 2:06:55 AM UTC+1, Hayashi a écrit :
Hi Conduition, Matt and Ethan
> an ownership proof used for non-BIP32 hashed addresses
I’m concerned that shared xpubs could become an attack vector if we allow
ZKP of hash preimages for unused addresses (excluding P2PK/P2TR). Given
that, are there alternative methods for publishing proof of ownership that
we should consider?
It seems the current default stance is effectively "do not freeze," because
preserving the status quo is the only path if we cannot reach consensus
(and if we do not chose hardfork). However, by formalizing a freezing
plan—either through a new BIP or an amendment to BIP361—I believe we gain
several strategic advantages:
*Clarity on P2MR discussion*: It would clarify the ongoing P2MR and P2TR
discussions by defining how P2TR will be treated (I personally prefer P2MR).
*Incentivized Migration*: Establishing a clear future plan encourages users
to migrate to BIP32-hardened addresses with longer time period which
eventually maximize recovery.
*Advance Planning for CRQCs*: We will not panic on the edge case scenario
that CRQCs arrive earlier than PQ signature scheme adoption or when we find
out we cannot allow enough migration period after PQ signature scheme
adoption (I strongly believe we also have to prepare for this future).
While further R&D is required, we likely have sufficient information to
formalize a framework now. We can also disable or modify the defined
freezing plan if the threat landscape changes significantly.
Hayashi
2026年4月11日土曜日 8:33:54 UTC+8 Ethan Heilman:
> IMO even something like P2MR's additional cost will strongly discourage
adoption.
I don't agree.
Over time as quantum attacks become a bigger and bigger concern for
holders, wallets will want to show that they can offer security against
CRQCs. This is especially true for wallets focused on high value Bitcoin
outputs. Even if someone thinks there is only a 2% chance they lose all
their Bitcoin because of a quantum computer, that 2% chance will keep them
up at night.
P2MR would have 17.25 more vBytes, an 11% overhead.
P2TR 1 input, 2 output - key path spend. 154 vbytes
P2MR 1 input, 2 output - spending a schnorr sig leaf of a P2MR output with
two leafs: 1. PQ sig leaf and 2. Schnorr sig leaf. 171.25 vbytes
I'm stacking the deck against P2MR here. Under some circumstances P2MR has
lower fees than P2TR.
It is hard to imagine someone holding significant quantities of Bitcoin not
wanting to pay 50 sats to ensure their Bitcoin isn't stolen by a quantum
computer.
On Fri, Apr 10, 2026 at 7:10 PM Matt Corallo <lf-l...@mattcorallo.com>
wrote:
On 4/10/26 1:03 PM, conduition wrote:
>> 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.
Right, but you cut my quote off and appear to be responding to a point I
didn't make? The very next
few words that you cut were "not only is it a likely prerequisite for an
alternative output type".
Yes, we have to figure out what kind of output type we want, whether P2MR
(360), P2TRv2 or just
P2TR. There are strong arguments for each. But none of that has any bearing
on whether we add hash
based signatures to tapscript. We have to add hash based signatures to
tapscript first no matter
what output type we want!
>> 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.
IMO even something like P2MR's additional cost will strongly discourage
adoption. We have a very
long history with Bitcoin wallets not only refusing to adopt new features
but actively making some
of the worst possible design decisions from a Bitcoin PoV. IMO we should
very strongly not give them
any excuse, even if that's just fees.
Matt
--
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/765490aa-5df3-4619-86cc-17570b6d3e99%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/a1aab08b-bea4-4dd9-a289-59994375849fn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 10893 bytes --]
next prev parent reply other threads:[~2026-04-13 14:23 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 [this message]
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
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=a1aab08b-bea4-4dd9-a289-59994375849fn@googlegroups.com \
--to=bitcoindev@googlegroups.com \
--cc=hayashi1225@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