From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 10 Apr 2026 18:07:02 -0700 Received: from mail-oo1-f56.google.com ([209.85.161.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wBMoP-0007tq-NK for bitcoindev@gnusha.org; Fri, 10 Apr 2026 18:07:02 -0700 Received: by mail-oo1-f56.google.com with SMTP id 006d021491bc7-683b5d81209sf5486116eaf.0 for ; Fri, 10 Apr 2026 18:07:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1775869615; x=1776474415; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :mime-version:subject:references:in-reply-to:message-id:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=ULBjhbfZeJC6/oXl8W0nLV+TyA8w/jIXHq95Z3ofgZE=; b=YH7EtBR5lFY39oPN1jbH/zMIcmnXcMKEb9vR0yWGnRDKKBDwY7/o7U/R7yK9DdiwPX ebqbpePUiuh35axB870vqIiTtxak+GUfYPmLGdMzff660/75JJ10w6kbc8LH/F/wz/qb btqa6dy3esSjVibmfSwLAEmHMxbDia0Itu1o2HCaSV5PwzwsLnyf4vGzQolLiFuIbhmW BGhM4sb2wyKsCp3adKHlZK4yVIAbJta1QyGV8RKMKulIFaA8oyQekH2iUr67K4klQM3w Et28kauwflGeQGWhgN+3M6gfkmEEPigrBTk0Qug1xhtbh07MtshBJVwsSqki4B9rHc9w 1FMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775869615; x=1776474415; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :mime-version:subject:references:in-reply-to:message-id:to:from:date :x-beenthere:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ULBjhbfZeJC6/oXl8W0nLV+TyA8w/jIXHq95Z3ofgZE=; b=AtAYMFkWoK3WJH6GVy1w3pXJq/rWVxi/VBSEDqggi+qSqME+lOuJ9B3kyn0wnXCgsv kCynv3hpQczGyTD2KULnaoPjilWXP792e1YVMiCt4vxzDIlQAzN0CbydoIQv2QZRlbHC 3Dt2ysp3cvdExe1kNPF3FUttm8VAubPHvJJYqOikC8MvhhTxPKafRAvwUdPRuzgJRMzI /vHg9muZhHTahjNJUe3Xal5JC61IMfeFwIEd//zuDpSp5qzDEUpPWQEQWm++4lG11uOH qZ+WU3VzJ1nHnaGjrdAVmmHKmFW6hpzi5uB78s68PV8qrX4ssd+RT4Pw5+4MZixsoFC+ mPSw== X-Forwarded-Encrypted: i=1; AJvYcCXG0qoi42ithGzFpK0alguK9+PQsPwaFcBRsA4RhK7vAWN827bcvn/i/4nj0cgxdBfoq13tUkEw6yfF@gnusha.org X-Gm-Message-State: AOJu0Ywvmo9i5Fnk+1kE9bjWiSS/cdxvKwowWpzQn3NhNIBTAhvsuh9R GJQnKVFkvYZQiq1pISocUxIoP5nnCWdkqZyo+ktWu2ngxnjTneK5OdSK X-Received: by 2002:a05:6820:1903:b0:67e:42b0:b35e with SMTP id 006d021491bc7-68be5e56d44mr2737591eaf.4.1775869615250; Fri, 10 Apr 2026 18:06:55 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiJvBLocA1bL02AgSrYy+42+OCBh0VFQC27dgGCxzy+dMA==" Received: by 2002:a05:6820:f010:b0:68a:d08b:c79f with SMTP id 006d021491bc7-68bc152f27cls1030706eaf.2.-pod-prod-05-us; Fri, 10 Apr 2026 18:06:50 -0700 (PDT) X-Received: by 2002:a05:6808:1456:b0:467:2418:ced9 with SMTP id 5614622812f47-4789fb05633mr2791342b6e.50.1775869610470; Fri, 10 Apr 2026 18:06:50 -0700 (PDT) Received: by 2002:a05:690c:fa:b0:79a:37dc:255a with SMTP id 00721157ae682-7ae1f2a0d56ms7b3; Fri, 10 Apr 2026 18:04:54 -0700 (PDT) X-Received: by 2002:a05:690c:8e16:b0:79a:c98d:2ba4 with SMTP id 00721157ae682-7af7282d8b9mr47655657b3.52.1775869493992; Fri, 10 Apr 2026 18:04:53 -0700 (PDT) Date: Fri, 10 Apr 2026 18:04:53 -0700 (PDT) From: "'Hayashi' via Bitcoin Development Mailing List" To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: <0vqF88LoOnY4GiUB4vf-MdeZpTAtR70tokS3cLwt2DX0e6_fD1X_wyhPwWEdIdm6R88AULObIU08CWsb5QfeoaM5c4yXPqN5wHyCrqMCtfQ=@protonmail.com> <6wBygQ_pK40ZpU_CMXfzIy-6LkthOmEh-xd2g9bwUl-f8w2K6G4rUWJEssE2zeJgxyipGe2GrFH9y_TUUI48asqfh7dhi9A2rl7NpWyFW1o=@proton.me> <765490aa-5df3-4619-86cc-17570b6d3e99@mattcorallo.com> Subject: Re: [bitcoindev] In defense of a PQ output type MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_75456_377246265.1775869493523" X-Original-Sender: hayashi1225@protonmail.com X-Original-From: Hayashi Reply-To: Hayashi 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: -0.7 (/) ------=_Part_75456_377246265.1775869493523 Content-Type: multipart/alternative; boundary="----=_Part_75457_801540281.1775869493523" ------=_Part_75457_801540281.1775869493523 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=20 ZKP of hash preimages for unused addresses (excluding P2PK/P2TR). Given=20 that, are there alternative methods for publishing proof of ownership that= =20 we should consider? It seems the current default stance is effectively "do not freeze," because= =20 preserving the status quo is the only path if we cannot reach consensus=20 (and if we do not chose hardfork). However, by formalizing a freezing=20 plan=E2=80=94either through a new BIP or an amendment to BIP361=E2=80=94I b= elieve we gain=20 several strategic advantages: *Clarity on P2MR discussion*: It would clarify the ongoing P2MR and P2TR=20 discussions by defining how P2TR will be treated (I personally prefer P2MR)= . *Incentivized Migration*: Establishing a clear future plan encourages users= =20 to migrate to BIP32-hardened addresses with longer time period which=20 eventually maximize recovery. *Advance Planning for CRQCs*: We will not panic on the edge case scenario= =20 that CRQCs arrive earlier than PQ signature scheme adoption or when we find= =20 out we cannot allow enough migration period after PQ signature scheme=20 adoption (I strongly believe we also have to prepare for this future). While further R&D is required, we likely have sufficient information to=20 formalize a framework now. We can also disable or modify the defined=20 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:54 UTC+8= Ethan Heilman: > > IMO even something like P2MR's additional cost will strongly discourag= e=20 > adoption. > > I don't agree. > > Over time as quantum attacks become a bigger and bigger concern for=20 > holders, wallets will want to show that they can offer security against= =20 > CRQCs. This is especially true for wallets focused on high value Bitcoin= =20 > outputs. Even if someone thinks there is only a 2% chance they lose all= =20 > their Bitcoin because of a quantum computer, that 2% chance will keep the= m=20 > 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 wit= h=20 > 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 ha= s=20 > lower fees than P2TR. > > It is hard to imagine someone holding significant quantities of Bitcoin= =20 > not wanting to pay 50 sats to ensure their Bitcoin isn't stolen by a=20 > quantum computer. > > > On Fri, Apr 10, 2026 at 7:10=E2=80=AFPM Matt Corallo =20 > wrote: > >> >> >> On 4/10/26 1:03 PM, conduition wrote: >> >> But as mentioned above I do not see why any addition of hash based=20 >> signatures to tapscript should require any kind of community consensus o= n=20 >> future disablement of insecure spend paths >> >=20 >> > I think Antoine's point here is that if we introduce a PQC opcode to= =20 >> tapscript but choose NOT to deploy P2MR, and then encourage people to us= e=20 >> that opcode in P2TR script leaves, then we are locking ourselves into th= e=20 >> assumption that the community will later disable P2TR key-path spending = -=20 >> otherwise those addresses will be compromised by a CRQC and the PQC leaf= =20 >> script is useless. >> >> Right, but you cut my quote off and appear to be responding to a point I= =20 >> didn't make? The very next=20 >> few words that you cut were "not only is it a likely prerequisite for an= =20 >> alternative output type".=20 >> Yes, we have to figure out what kind of output type we want, whether P2M= R=20 >> (360), P2TRv2 or just=20 >> P2TR. There are strong arguments for each. But none of that has any=20 >> bearing on whether we add hash=20 >> based signatures to tapscript. We have to add hash based signatures to= =20 >> tapscript first no matter=20 >> what output type we want! >> >> >> Adding a PQ output type which no one will use (eg one where use of th= e=20 >> hash-based signature is mandatory, which drives fees up hugely and has a= ll=20 >> the drawbacks you mention) is not a risk mitigation strategy - it does n= ot=20 >> materially allow for any migration and doesn't accomplish much of anythi= ng.=20 >> But as mentioned above I do not see why any addition of hash based=20 >> signatures to tapscript >> >=20 >> > I don't think anyone is suggesting deployment of an output type with= =20 >> mandatory hash-based signatures. That would be borderline unusable for= =20 >> anyone but large companies and wealthy elites. >> >=20 >> > Every decent proposal I've seen has suggested using PQC in tandem with= =20 >> ECC across multiple tapscript leaves, whether in some bastardized varian= t=20 >> of P2TR, or in BIP360's P2MR. >> >> IMO even something like P2MR's additional cost will strongly discourage= =20 >> adoption. We have a very=20 >> long history with Bitcoin wallets not only refusing to adopt new feature= s=20 >> but actively making some=20 >> of the worst possible design decisions from a Bitcoin PoV. IMO we should= =20 >> very strongly not give them=20 >> any excuse, even if that's just fees. >> >> Matt >> >> --=20 >> You received this message because you are subscribed to the Google Group= s=20 >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to bitcoindev+...@googlegroups.com. >> > To view this discussion visit=20 >> https://groups.google.com/d/msgid/bitcoindev/765490aa-5df3-4619-86cc-175= 70b6d3e99%40mattcorallo.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/= e737199f-6a69-4d2a-97b8-d9c4aad5f33bn%40googlegroups.com. ------=_Part_75457_801540281.1775869493523 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Conduition, Matt and Ethan

> an ownership proof used for n= on-BIP32 hashed addresses
I=E2=80=99m concerned that shared xpubs coul= d become an attack vector if we allow ZKP of hash preimages for unused addr= esses (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 pr= eserving 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 several strategic advantages:

Clarity on P2MR discussion= : It would clarify the ongoing P2MR and P2TR discussions by defining ho= w P2TR will be treated (I personally prefer P2MR).

Incentiviz= ed Migration: Establishing a clear future plan encourages users to migr= ate to BIP32-hardened addresses with longer time period which eventually ma= ximize 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 perio= d after PQ signature scheme adoption (I strongly believe we also have to pr= epare for this future).

While further R&D is required, we li= kely 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=E5=B9=B44=E6=9C=8811=E6=97=A5=E5= =9C=9F=E6=9B=9C=E6=97=A5 8:33:54 UTC+8 Ethan Heilman:
>=C2=A0 IMO even something like P2MR's additional cost will strongly discourage= adoption.

I don't agree.

Over tim= e as quantum attacks become a bigger and bigger concern for holders, wallet= s will want to show that they can offer security against CRQCs. This is esp= ecially true for wallets focused on high value Bitcoin outputs. Even if som= eone thinks there is only a 2% chance they lose all their Bitcoin because o= f a quantum computer, that 2% chance will keep them up at night.

P2M= R would have 17.25 more vBytes, an 11% overhead.

P2TR 1 input, 2 out= put - key path spend. 154 vbytes
P2MR=20 1 input, 2 output - spending a=C2=A0schnorr sig leaf of a P2MR output with = two leafs: 1. PQ sig leaf and 2. Schnorr sig leaf.=C2=A0171.25 vbytes
I'm stacking the deck against=C2=A0P2MR here. Under some circumstance= s P2MR has lower fees than P2TR.

It is hard to imagine someone holdi= ng significant quantities of Bitcoin not wanting to pay 50 sats=C2=A0to ens= ure their Bitcoin isn't stolen by a quantum computer.


=
On Fri, 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 tapscript but choose NOT to deploy P2MR, and then encourage people to us= e 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 sc= ript 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 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 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 = anything. But as mentioned above I do not see why any addition of hash base= d signatures to tapscript
>
> I don't think anyone is suggesting deployment of an output type wi= th mandatory hash-based signatures. That would be borderline unusable for a= nyone 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 vari= ant 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 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 &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+...@googlegro= ups.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 &= 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/bitcoind= ev/e737199f-6a69-4d2a-97b8-d9c4aad5f33bn%40googlegroups.com.
------=_Part_75457_801540281.1775869493523-- ------=_Part_75456_377246265.1775869493523--