From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 15 Apr 2026 12:07:19 -0700 Received: from mail-oa1-f59.google.com ([209.85.160.59]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wD5a2-0001Cu-Fq for bitcoindev@gnusha.org; Wed, 15 Apr 2026 12:07:19 -0700 Received: by mail-oa1-f59.google.com with SMTP id 586e51a60fabf-415e1ea16b4sf13443448fac.1 for ; Wed, 15 Apr 2026 12:07:17 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1776280032; cv=pass; d=google.com; s=arc-20240605; b=gQ5nSEagNWAbMjIW45pFN5GgX+mcxiL6I93Z9Ijzdnv/Ddn5/pHigTRLH8rhFyU99r cQB3rYbb1cAr3qcNGQGCz/cHtFaRJ2NpK+SOFqUNN3/jS+NiRWMpMQDrOXaVI2TN4UtS gBxtAoRQkMocmF/GZsQNrSSbYkYb5amwp7M/4dDFaqU83CKlZ1pbxBN7O9In0WelVrEv 0YZTkrHviFJzbOqUBKExaDaeZRQX72zaMic2bYxQTY95S04oRVpqlVE2YPGjB2PHxswx 0kMk6LheHiGmRbxbFXV8uWkA7MfRozO4ybjdB6kOhXOTE3Jz3eWxg1wpYugWVQ5B/T3q ejag== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=VitOZjeqCMSJTtKwgbWDXQZ5eVD24e593oxlOR5Q7VE=; fh=xtnXn3N3W38b1UEv1mxErLWpi4G1Sc/QKOjnj0Ekd6E=; b=DbaiE5VxUsGtn4+KoKMchJj92hiOF4Vu0tHKRNiKArX4TuBtXTdSqW1QBBk4bD95ZJ pXIv14W6bVGpYLlxAoNYZU9lbcT3oJdIjtDOm+wsHFiJyaXtStNSbKjJw8BzH2/Coqyu gPN4DRETELNfZkX0n396XjwXoKcJ/G8hGEV+bVSEq6AePcOW1quH9io2siKRdKxBDLWK +6F66W2rwVbvUDYFCb9q6kuY70Ukp/0kPRHsxTPQKgOawfEEFDkTeJa6JRZR+S4vbcwo 2lV7TEBXlYbYptV920WAKg8rRJCBY3IbbnUKkcLbzxgTYBQ9ah8J5IVwXwcAnwgO+Rum klPA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=R+XMN9uT; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.101 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1776280032; x=1776884832; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:from:to:cc:subject:date:message-id:reply-to; bh=VitOZjeqCMSJTtKwgbWDXQZ5eVD24e593oxlOR5Q7VE=; b=iiWbcZY009jc4ESuvHeqE7CyyMurWp4qStl3c+EbTcO3PT/PhBVWp5efa9F6jL3E/u /baYeqZci63BgYt/mQlCPYmASSkOz5XfiaOEjl6zrn8mEP72sGezXrSxn0/LlXLb1kSr ZLjPEDAsc7oTCZPiclb77QSkwGPwg6rANAAbeBBH+sKJDORG5bLO1Ug46pMBzf/BbxRg yd9JZJ5hDhJFnTsvogiG78Y0kjf0WTO0h9lR9CeoFluPKpcWdteq7CdoLFjcBVAx/TSN o4+xfRyhCBHedx29tRQn62vgm1szDT3+mox3KPJxSCHHJxItD88f6f+ENh4wijsJduzy e1hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776280032; x=1776884832; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=VitOZjeqCMSJTtKwgbWDXQZ5eVD24e593oxlOR5Q7VE=; b=dGLYNVdTH6F/ndu22OZcakkVSsWB496K42Lv0nJyb3bQ02NBaNIrRs8gIt/wpkBXiO kWpzmXI8MyO3PUdntjyAVvs5yM48oQ0VSaQ9SqVDpUXKTGN4v9tzKOz7VjdDcArT0lDg fRYZ0fzxFxA7V5MwPN+VbmoUOimsAQ0TkJ+UbvxyG4gG6y6glmAsMbQcrh+3EFLL02Hz JDOxh7otNsL/PcTCOpVumo/heOi1QPnKN+Cj+p7wKccpPnPl6E4e7ay248tjmdCtrV8z Kb/till0ZmIRdPAuLRz/DiwEUIftQeYa0GQtGkUKaeHPjTqSmAp9SajAkgPNiYvgR6Sy X8dg== X-Forwarded-Encrypted: i=2; AFNElJ/K+mJXR5D9jlwI3LVbherQMdfHiWsj0CtflyNWowtxfXth5SPBpo+Xwn2YSe0RIYd5h0fK11qCPuQC@gnusha.org X-Gm-Message-State: AOJu0YyA5SlmE7CnPis/kWVgYIpgt+cRKHRtApP3LgHWYpWl03rXc39G gl7aCSzTB3Gp19YE4JPxFn53r90J2NhRM4EKeOTfqEEH6Pd1YBlC7wSx X-Received: by 2002:a4a:e916:0:b0:67b:a667:f53e with SMTP id 006d021491bc7-68be56818e7mr11579664eaf.1.1776280031889; Wed, 15 Apr 2026 12:07:11 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiKshiNXX5fDFGMnKaNijo9uQqegsIwBTvnn91sZiUhsXg==" Received: by 2002:a05:6870:56ab:b0:423:2c4e:f150 with SMTP id 586e51a60fabf-4280c4ce33als76440fac.1.-pod-prod-03-us; Wed, 15 Apr 2026 12:07:07 -0700 (PDT) X-Received: by 2002:a05:6808:6d97:b0:46a:7718:c525 with SMTP id 5614622812f47-4789f50febemr11297964b6e.32.1776280027035; Wed, 15 Apr 2026 12:07:07 -0700 (PDT) Received: by 2002:aa7:df08:0:b0:670:312d:f74b with SMTP id 4fb4d7f45d1cf-67228b28a65msa12; Wed, 15 Apr 2026 12:05:57 -0700 (PDT) X-Received: by 2002:a05:6402:4409:b0:66e:d2ad:bf4b with SMTP id 4fb4d7f45d1cf-6707a475b82mr12541344a12.15.1776279955165; Wed, 15 Apr 2026 12:05:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776279955; cv=none; d=google.com; s=arc-20240605; b=JyqzuYyPfkD7v1PRAclS/UtrAtYWHz2F6hxWo1ytDkSOKTVIZ9YOYWu1HSMCgTR8+V u0M243l+o03gCqsWPleVty0k6HfcYNzGqpYSb7AqgV9kUea7j+n/8VdWpkGhqVJubkT3 mjAUmFeJX86Mg9gugx+2gQMCdsHR/GlG3LkHJmXORsLxMwf8RaWrgkQ99NQqNFrbSxqR 6gY7aR2cYlyUyeUEgym6/AFQ/SA1zGq7XsXdnekZ4ok2Aoi+8+n3TbSQkrc7CA+w1+v9 JNVgnlYzcjIkUhaLPK9hhy0pKGovFtwSDbWG1MRDDVT+sB9k4PHJFDCFjQu+IYQukBvH Qpgw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=em6UkE7yyoBKzbR5wn0E5x93xCzI0r6zE7J8CQT+Vvg=; fh=sapDHqhE46zLmMBeB1lkoe0zq8J9+V3Afx71/j8kvug=; b=ZPtJQx3dHVuFp5QDII8ybH3uXxTjprmfi+rRVNnD2D4UpOO4IEifk4806iS+qx+l9l oaooV/HxY5lPwIOXxttPy39f/O3SBbhi2NrT6cmAZukMYE8YpwT4SB9Zpzo/83lKoErc p1ytsafowRK+TO8Kjom7pVXlLZLzSjRucAhFFDv2U7mpTWH8GWtP2A7R8iGGFBv6+9V2 UJEjp/ofH8e+YGptZ8ji2lNRMe2y5HPHpiSZw0tfSwrAOMtaqQzs4KnhWa9E73Xte2kC 6cj+ZOqjmY+oDq7gkr60N0cOkgUHEzHy+OkGFzkjmQ2YoGfKIMUuXnk3b/5HrUutA3dh Swsg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=R+XMN9uT; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.101 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-43101.protonmail.ch (mail-43101.protonmail.ch. [185.70.43.101]) by gmr-mx.google.com with ESMTPS id 4fb4d7f45d1cf-67238005355si47863a12.6.2026.04.15.12.05.55 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Apr 2026 12:05:55 -0700 (PDT) Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 185.70.43.101 as permitted sender) client-ip=185.70.43.101; Date: Wed, 15 Apr 2026 19:05:47 +0000 To: Antoine Riard From: "'Antoine Poinsot' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] In defense of a PQ output type Message-ID: <3PuZlWnztVG7MIcejfM8UHiKB9GNqaGsQX4JmsfLMINPs84FaAp7OZ7EdTxPYV-O2XUJQWM_eYUND3Pm-fHnBcv9QXdHKasHjgacNrE-K-o=@protonmail.com> In-Reply-To: <459bd81c-584f-4adf-9112-bb733d381c99n@googlegroups.com> References: <0vqF88LoOnY4GiUB4vf-MdeZpTAtR70tokS3cLwt2DX0e6_fD1X_wyhPwWEdIdm6R88AULObIU08CWsb5QfeoaM5c4yXPqN5wHyCrqMCtfQ=@protonmail.com> <6wBygQ_pK40ZpU_CMXfzIy-6LkthOmEh-xd2g9bwUl-f8w2K6G4rUWJEssE2zeJgxyipGe2GrFH9y_TUUI48asqfh7dhi9A2rl7NpWyFW1o=@proton.me> <765490aa-5df3-4619-86cc-17570b6d3e99@mattcorallo.com> <459bd81c-584f-4adf-9112-bb733d381c99n@googlegroups.com> Feedback-ID: 7060259:user:proton X-Pm-Message-ID: 436b8d502ad89da2a5114346b2caac6404dc1c4b MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_HONzVIaU1k12QtswDgzBD8oUmdPvUX9cFhhIk4YuAZk" X-Original-Sender: darosior@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=R+XMN9uT; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.101 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: Antoine Poinsot Reply-To: Antoine Poinsot Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -1.0 (-) --b1=_HONzVIaU1k12QtswDgzBD8oUmdPvUX9cFhhIk4YuAZk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, > I don't think in this thread the question is raised to enable to secure o= ne's coin under double classic cryptogrraphic assumption and PQ assumption,= i.e "hybrid" security Yes. I'm assuming that a hash-based scheme would be reasonable to introduce= on its own (as opposed to more fancy schemes). But i'm also not sure it's = possible to guarantee that hybrid security is used, since a user can always= choose to use a dummy secret for one of the two signature challenges. Best, Antoine On Friday, April 10th, 2026 at 9:28 PM, Antoine Riard wrote: > 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: 6d7c2f5ab01bcdda4ec27d4c21198a9b13ce1dfd138c4a2e6dfaedee9458f6c= 0 > > Le Saturday, April 11, 2026 =C3=A0 2:06:55=E2=80=AFAM UTC+1, Hayashi a = =C3=A9crit : > >> Hi Conduition, Matt and Ethan >> >>> an ownership proof used for non-BIP32 hashed addresses >> I=E2=80=99m 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 ownershi= p that we should consider? >> >> It seems the current default stance is effectively "do not freeze," beca= use 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= =E2=80=94either through a new BIP or an amendment to BIP361=E2=80=94I belie= ve we gain several strategic advantages: >> >> Clarity on P2MR discussion: It would clarify the ongoing P2MR and P2TR d= iscussions by defining how P2TR will be treated (I personally prefer P2MR). >> >> Incentivized Migration: Establishing a clear future plan encourages user= s to migrate to BIP32-hardened addresses with longer time period which even= tually 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 adop= tion (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 freezi= ng plan if the threat landscape changes significantly. >> >> Hayashi >> 2026=E5=B9=B44=E6=9C=8811=E6=97=A5=E5=9C=9F=E6=9B=9C=E6=97=A5 8:33:54 UT= C+8 Ethan Heilman: >> >>>> IMO even something like P2MR's additional cost will strongly discourag= e adoption. >>> I don't agree. >>> >>> Over time as quantum attacks become a bigger and bigger concern for hol= ders, 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 Bitco= in 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 w= ith 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 quant= um computer. >>> >>> On Fri, Apr 10, 2026 at 7:10=E2=80=AFPM Matt Corallo wrote: >>> >>>> On 4/10/26 1:03 PM, conduition wrote: >>>>>> But as mentioned above I do not see why any addition of hash based s= ignatures to tapscript should require any kind of community consensus on fu= ture 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 t= hat opcode in P2TR script leaves, then we are locking ourselves into the as= sumption that the community will later disable P2TR key-path spending - oth= erwise those addresses will be compromised by a CRQC and the PQC leaf scrip= t 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 P= 2MR (360), P2TRv2 or just >>>> P2TR. There are strong arguments for each. But none of that has any be= aring 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 t= he hash-based signature is mandatory, which drives fees up hugely and has a= ll the drawbacks you mention) is not a risk mitigation strategy - it does n= ot materially allow for any migration and doesn't accomplish much of anythi= ng. But as mentioned above I do not see why any addition of hash based sign= atures 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 anyo= ne but large companies and wealthy elites. >>>>> >>>>> Every decent proposal I've seen has suggested using PQC in tandem wit= h 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 discourag= e adoption. We have a very >>>> long history with Bitcoin wallets not only refusing to adopt new featu= res but actively making some >>>> of the worst possible design decisions from a Bitcoin PoV. IMO we shou= ld 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 Gro= ups "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/bitcoi= ndev/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/bitcoinde= v/459bd81c-584f-4adf-9112-bb733d381c99n%40googlegroups.com. --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 3PuZlWnztVG7MIcejfM8UHiKB9GNqaGsQX4JmsfLMINPs84FaAp7OZ7EdTxPYV-O2XUJQWM_eYU= ND3Pm-fHnBcv9QXdHKasHjgacNrE-K-o%3D%40protonmail.com. --b1=_HONzVIaU1k12QtswDgzBD8oUmdPvUX9cFhhIk4YuAZk Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I don't think in t= his thread the question is raised to enable to secure one's coin under= double classic cryptogrraphic assumption and PQ assumption, i.e "hybr= id" security
=20
=20
=20

<= div style=3D"font-family: Arial, sans-serif; font-size: 14px;">Yes. I'm ass= uming that a hash-based scheme would be reasonable to introduce on its own = (as opposed to more fancy schemes). But i'm also not sure it's possible to = guarantee that hybrid security is used, since a user can always choose to u= se a dummy secret for one of the two signature challenges.

Best,
Antoine
On Friday, April 10th, 2026 at 9:28 PM, Antoine Riard <antoine.r= iard@gmail.com> wrote:
Hi,

Thanks for rolling up the ball forward on this topic= .

I'm +1 on disentangling the introduction of a PQ safe scheme from<= br>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 soun= ds 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 ho= w freezing help here, from the more loose idea of
ensuring there is no c= rash in the bitcoin price vs fiat in the face
of CQRC-enabled attacks, w= hich 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 att= ackers), I believe there are still
intermediary technical solutions, e.g= rate-limiting the number of output
types that can be spent by difficult= y periods to minimize the risks of
disruptions, while not technically co= nfiscating 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 migh= t
more a real engineering burden, though I believe it's giving more
f= lexibility 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 dev= elopment 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,
A= ntoine
OTS hash: 6d7c2f5ab01bcdda4ec27d4c21198a9b13ce1dfd138c4a2e6dfaede= e9458f6c0

Le Saturday, April 11, 2026 =C3=A0 2:06:55=E2=80=AFAM UTC+1, Hayash= i a =C3=A9crit :
Hi Conduition, Matt and Ethan

> an ownership proof used for no= n-BIP32 hashed addresses
I=E2=80=99m concerned that shared xpubs could b= ecome an attack vector if we allow ZKP of hash preimages for unused address= es (excluding P2PK/P2TR). Given that, are there alternative methods for pub= lishing 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=E2=80=94either= through a new BIP or an amendment to BIP361=E2=80=94I believe we gain seve= ral strategic advantages:

Clarity on P2MR discussion: It woul= d clarify the ongoing P2MR and P2TR discussions by defining how P2TR will b= e treated (I personally prefer P2MR).

Incentivized Migration:= Establishing a clear future plan encourages users to migrate to BIP32-hard= ened addresses with longer time period which eventually maximize recovery.<= br>
Advance Planning for CRQCs: We will not panic on the edge cas= e scenario that CRQCs arrive earlier than PQ signature scheme adoption or w= hen 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 info= rmation to formalize a framework now. We can also disable or modify the def= ined freezing plan if the threat landscape changes significantly.

Hayashi
2026=E5=B9=B44=E6=9C=8811=E6=97=A5=E5=9C=9F=E6=9B=9C=E6=97=A5 8:33:5= 4 UTC+8 Ethan Heilman:
>=20 IMO even something like P2MR's additional cost will strongly discourage ado= ption.

I don't agree.

Over time as qua= ntum attacks become a bigger and bigger concern for holders, wallets will w= ant to show that they can offer security against CRQCs. This is especially = true for wallets focused on high value Bitcoin outputs. Even if someone thi= nks there is only a 2% chance they lose all their Bitcoin because of a quan= tum 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 - ke= y path spend. 154 vbytes
P2MR 1 input, 2 output - spending a schnorr sig leaf of a P2MR output with two l= eafs: 1. PQ sig leaf and 2. Schnorr sig leaf. 171.25 vbytes

I'm stac= king the deck against P2MR here. Under some circumstances P2MR has lower fe= es than P2TR.

It is hard to imagine someone holding significant quan= tities of Bitcoin not wanting to pay 50 sats to ensure their Bitcoin isn't = stolen by a quantum computer.


<= /div>
On Fr= i, Apr 10, 2026 at 7:10=E2=80=AFPM 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 t= apscript but choose NOT to deploy P2MR, and then encourage people to use th= at opcode in P2TR script leaves, then we are locking ourselves into the ass= umption that the community will later disable P2TR key-path spending - othe= rwise 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 di= dn't make? The very next
few words that you cut were "not only is it a likely prerequisite for an al= ternative 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 taps= cript 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 anyt= hing. But as mentioned above I do not see why any addition of hash based si= gnatures to tapscript
>
> I don't think anyone is suggesting deployment of an output type with m= andatory hash-based signatures. That would be borderline unusable for anyon= e 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 ado= ption. We have a very
long history with Bitcoin wallets not only refusing to adopt new features b= ut actively making some
of the worst possible design decisions from a Bitcoin PoV. IMO we should ve= ry 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 e= mail to bitcoindev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/765490aa-5df3-4619-86cc-1= 7570b6d3e99%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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/= d/msgid/bitcoindev/459bd81c-584f-4adf-9112-bb733d381c99n%40googlegroups.com= .

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 3PuZlWnztVG7MIcejfM8UHiKB9GNqaGsQX4JmsfLMINPs84FaAp7OZ7EdTxPYV-O2XUJQWM_eYU= ND3Pm-fHnBcv9QXdHKasHjgacNrE-K-o%3D%40protonmail.com.
--b1=_HONzVIaU1k12QtswDgzBD8oUmdPvUX9cFhhIk4YuAZk--