From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 06 Jun 2026 11:00:21 -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 1wVvJj-00072g-RC for bitcoindev@gnusha.org; Sat, 06 Jun 2026 11:00:21 -0700 Received: by mail-oo1-f56.google.com with SMTP id 006d021491bc7-69e365a9d0esf2598590eaf.2 for ; Sat, 06 Jun 2026 11:00:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1780768812; x=1781373612; 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=C474gluONxDSZjuAnvC3R5HtTX9E/SH23R3Fjn9C8YQ=; b=jHsATx04O3zbC5HmCB6VciKn/riMrGpmGwLlFmpyQk/WtkVFaFLe5AkoPWy6y0Lbg2 FSdltN01299X5dd0i53zo75E5Y7Y/CMVTV436Ln0MWzXAxFQlfk4oxEftsVTsBd/ijCr vBbk5yIo+ivK1QbG7+wszdHIKlRSD5Lv7okjLNn9he6x5VHIz4ElqeKd+4ctJvGUt37I Hqyg4oqHFs7InW4kMIs+VcESmp9HK0eSVQ3svV5w1WGH8m60P6g+ZRWlngFpbWrk2SZQ 4U4T6+8CqeFFwPOFDghQSFJqtU5RQ3yS5AYbjprLcU+awIRSET/fosZ0bHyJiy40Tdb7 POLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780768812; x=1781373612; 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=C474gluONxDSZjuAnvC3R5HtTX9E/SH23R3Fjn9C8YQ=; b=UWB9HC0EQWvD+QzYxfXgri57UOd4kWyx2ouy2K3NCL5R2+qtU+knylIYLRS7vx/7cz wZ21xd69CEQhAzAFAXsf6y15dxM6oVnWkP73OarimxcDF1/g4Tp/4jL3nQqQbTxjjnP9 2fdVksa4sQL+hD55rTcvA6+ondSowtgwfuvaH7GTjCEc2DfTCbT4BEeZWs5WAJ3TzxBS wqukdLBaN/MFy7walKQ/jNd2h/c/MJJyzeR6aajujn/rRsDFmO9tveolh2I+lJf2drr2 E39C0YeFVmO8PKTW8vwDoYsSyxV0o+fkd0weVcklfbf0Uj3Xr4y0Ca84B3A7hMi9D1bM acnw== X-Forwarded-Encrypted: i=1; AFNElJ/1Juo0kvAuU2lNBBUezpG5yxQ0qxL9Es5NYngON8CFL4CNsErkTMeGFEvGxnvPk/PUsFLp9o/oXZX1@gnusha.org X-Gm-Message-State: AOJu0Yy1K0sUnCzismA9F5rS4zOX3QlZ8qvuAQun0tAaTu/99N5oyzHu JxTOmHsmV6XOwvpOHGiKMY26eOG9q9wEoe4dfqhhxjAlcYSfI2cFni7Z X-Received: by 2002:a05:6820:4a01:b0:69d:82e6:69e4 with SMTP id 006d021491bc7-69e68c7ecaamr4429131eaf.47.1780768811629; Sat, 06 Jun 2026 11:00:11 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUf6R8swKtFf9yPtjVAa7E/+LQKUQjXB9DUc704ZKCgYTA==" Received: by 2002:a05:6871:597:10b0:43b:781c:b5e with SMTP id 586e51a60fabf-44109e37250ls1647576fac.1.-pod-prod-03-us; Sat, 06 Jun 2026 11:00:07 -0700 (PDT) X-Received: by 2002:a05:6808:6901:b0:485:1174:4582 with SMTP id 5614622812f47-4868de24ed6mr5441287b6e.13.1780768807406; Sat, 06 Jun 2026 11:00:07 -0700 (PDT) Received: by 2002:a05:690c:c1e:b0:7ba:f5aa:4ab8 with SMTP id 00721157ae682-7ed27751347ms7b3; Sat, 6 Jun 2026 10:52:48 -0700 (PDT) X-Received: by 2002:a05:690c:4441:b0:7e2:b35a:adbf with SMTP id 00721157ae682-7ed0f434ccfmr86089017b3.38.1780768367613; Sat, 06 Jun 2026 10:52:47 -0700 (PDT) Date: Sat, 6 Jun 2026 10:52:46 -0700 (PDT) From: "'Hayashi' via Bitcoin Development Mailing List" To: Bitcoin Development Mailing List Message-Id: <76e281e7-c4b4-4267-9bda-edfd2ee19dc0n@googlegroups.com> In-Reply-To: References: Subject: Re: [bitcoindev] Aligning privacy incentives in P2MR MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_66048_1323652623.1780768366965" 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_66048_1323652623.1780768366965 Content-Type: multipart/alternative; boundary="----=_Part_66049_813271033.1780768366965" ------=_Part_66049_813271033.1780768366965 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Conduition, Antonie, and list, A reasonable intersection of both opinions could be further witness=20 discount of EC Schnorr of P2MR (Segwit v2).=20 Further 2x witness discount (total 8x witness discount) makes P2MR EC-spend= =20 transaction cost almost at par with P2TRv2 key-spend path. Anyway, we will have to discuss discount policy when we try to add PQ=20 signature to Bitcoin. I think we could discount witness for those who use= =20 EC Schnorr leaf if larger transaction cost heavily discourages the=20 migration. Best Regards, Hayashi On Saturday, 6 June 2026 at 6:59:18=E2=80=AFam UTC+8 conduition wrote: > Hi Antoine, thanks for the feedback. Glad to hear you're receptive! > > It's important to consider that in any scenario where Bitcoin as we know= =20 > it survives a CRQC, the vast majority of users would have had to migrate = to=20 > an output type that includes an escape hatch long before we could have be= en=20 > reasonably certain that a CRQC would materialize. Therefore we should not= =20 > assume that the vast majority of users strongly desire to migrate to an= =20 > escape-hatch output type. (In fact, i think it would actually be reasonab= le=20 > to assume none have a strong desire to do so. This is because everyone ha= s=20 > an incentive for everybody to migrate, but there is little incentive for= =20 > each individual to migrate if nobody else does.) > > > Therefore any additional barrier to encourage users to opt into an=20 > escape-hatch output type is working against CRQC risk mitigation. > > > All else being equal, whether we use P2MR or P2TRv2 I believe we will end= =20 > up with roughly the same (small) fraction of the UTXO set migrated by=20 > Q-day. I believe this because address format adoption is always slow even= =20 > with good incentives. Even after 7 years and plenty of incentives to=20 > migrate, P2TR still secures only a small fraction of the UTXO-set compare= d=20 > to P2(W)PKH, and a tiny fraction (0.75%) of the supply. See this 2025=20 > report from mempool.space=20 > and this 2025 report=20 > from Galaxy Digital=20 > . Inc= entivizing=20 > adoption doesn't always lead to adoption, so why expect it to do so with= =20 > P2TRv2? It doesn't offer any incentive over P2TR beyond a shallow promise= =20 > of *maybe-some-day-quantum-security*. > > Here's my timeline prediction, with the above precedent in mind. We deplo= y=20 > a PQ output type, some minority of UTXOs migrate to it. When the first=20 > confirmed ECDLP break is proven (e.g. if someone breaks a NUMS point) or= =20 > suspected (someone stole Satoshi's coins), then we will deploy a rescue= =20 > protocol which we hopefully prepared in advance to protect the majority= =20 > procrastinator UTXOs. Maybe we disable EC spending at the same time (a=20 > valid option for either P2MR or P2TRv2). Then there will be a brief=20 > fork-war (hard or soft) revolving around the question of how to handle=20 > Satoshi's coins. After that IDK what happens, but I expect Bitcoin will= =20 > survive if we prepare adequately today by deploying a quantum-safe addres= s=20 > format and PQ signature scheme, and develop rescue protocols for later=20 > activation to move laggards over to PQ wallets. > > Whether we pick P2MR or P2TRv2 today, neither choice will affect the earl= y=20 > stages of this plot-line very much, so we might as well optimize for the= =20 > long-term future, and P2MR wins out there. > > any additional barrier to encourage users to opt into an escape-hatch=20 > output type is working against CRQC risk mitigation. And i think the=20 > additional costs of using P2MR compared to P2TRv2 is one of them. > > > I have good news for you: there is an optimization to BIP360 which would= =20 > make single-signer Schnorr spending significantly (32 bytes) cheaper. It'= s=20 > not my idea so I don't want to jump the gun in explaining the details, bu= t=20 > expect another mailing list post soon with more info. > > regards, > conduition > On Friday, June 5th, 2026 at 3:56 PM, Antoine Poinsot < > daro...@protonmail.com> wrote: > > Hi conduition, > > I think this would address the perverse incentive concern, but still fail= =20 > in not disincentivizing mass migration. > > It's important to consider that in any scenario where Bitcoin as we know= =20 > it survives a CRQC, the vast majority of users would have had to migrate = to=20 > an output type that includes an escape hatch long before we could have be= en=20 > reasonably certain that a CRQC would materialize. Therefore we should not= =20 > assume that the vast majority of users strongly desire to migrate to an= =20 > escape-hatch output type. (In fact, i think it would actually be reasonab= le=20 > to assume none have a strong desire to do so. This is because everyone ha= s=20 > an incentive for everybody to migrate, but there is little incentive for= =20 > each individual to migrate if nobody else does.) > > Therefore any additional barrier to encourage users to opt into an=20 > escape-hatch output type is working against CRQC risk mitigation. And i= =20 > think the additional costs of using P2MR compared to P2TRv2 is one of the= m.=20 > Most likely all "long-tail" users, who would be the least likely to seek= =20 > migration, use single-key spending policies. In fact, most Bitcoin users= =20 > do: in the past 90 days of blocks, 93.6% of all transaction inputs are=20 > for single-key spending policies=20 > . For a typical= =20 > 2-input 2-output transaction for a "single-key wallet", P2MR is about 15%= =20 > more expensive to use than P2TRv2 [^0]. > > I understand that P2MR does not introduce this additional cost just for= =20 > kicks, but i think "long-range" protection is a red-herring and not worth= =20 > hindering individual migration to the escape-hatch output type, which is= =20 > critical to the systemic migration of Bitcoin away from relying on EC=20 > cryptography. > > So your proposal does address one of my concerns with a P2MR + PQ opcode= =20 > strategy. However, i still believe P2TRv2 to be a superior strategy for t= he=20 > reason outlined above. > > Best, > Antoine > > [^0]: Using 57.5*2 + 43*2=20 > =3D 201 vbytes as the= =20 > base size. P2MR adds an additional 32 witness bytes in the control block= =20 > for the PQ spend path, and an additional 35 witness bytes for the EC leaf= =20 > script reveal. That's 33.5 more vbytes per input, which is 116.66% the si= ze=20 > of the same transaction with P2TRv2. > On Wednesday, June 3rd, 2026 at 7:26 PM, 'conduition' via Bitcoin=20 > Development Mailing List wrote: > > Hi list. I'm following up on an idea I sketched in this thread debating= =20 > P2MR vs P2TRv2 .=20 > > The premise is this: What if we modified this line of BIP360: > > The last stack element is called the control block c, and must have lengt= h=20 > 1 + 32 * m, for a value of m that is an integer between 0 and 128,=20 > inclusive. Fail if it does not have such a length. > > > To this: > > The last stack element is called the control block c, and must have lengt= h=20 > 1 + 32 * m, for a value of m that is an integer between *1* and 128,=20 > inclusive. Fail if it does not have such a length. > > > The key change is that the control block must now include at least one=20 > merkle authentication path. This effectively bans depth-zero script trees= =20 > in P2MR, and requires every P2MR address to always pay the cost of having= =20 > at least two spending conditions. > > This seems like a reduction in P2MR's features and efficiency. Why would= =20 > we want to ban depth-zero script trees? Well these seem to be the source= =20 > of a perverse incentive, as pointed out by Matt Corallo and Antoine Poins= ot=20 > in prior threads .= =20 > Bitcoin script users are economically and practically incentivized by P2M= R=20 > to use depth-zero script trees because their witnesses are *smaller* than= =20 > if the same script were used in a taproot script spend. > > Furthermore, depending on the exact scripts and the developers' resources= ,=20 > devs using P2MR for a multi-party scripting protocol may not be=20 > sufficiently incentivized to add a cooperative spending path, even if the= ir=20 > protocol might allow it. Doing so would require a depth-1 tree, which=20 > increases the witness size of the non-cooperative script spend path by 32= =20 > bytes. For some short scripts, e.g CLTV CHECKSIG=E2=80= =8B, the=20 > devs may actually have incentive *not* to add a cooperative spending=20 > path, because the cooperative path would actually be *less-efficient*=20 > than just using the non-cooperative path as the single leaf of a depth-ze= ro=20 > tree. This leads to easy fingerprinting of scripting protocols, less=20 > privacy for everyone else, and undoes a key design goal of P2TR. > > In Matt's words=20 > : > > The value of taproot is that its design natively adds [a cooperative=20 > spending path] *for free* to every contracting protocol, and not only add= s=20 > it for free but *forces* every contracting protocol to carry at least som= e=20 > of the cost if they decline to do this. This results in a massive net=20 > privacy win across the entire Bitcoin ecosystem... > > > a goal of taproot is *privacy* while offering efficiency for the common= =20 > (all-sign) case. That is generally true across contracting protocols and= =20 > makes things net-cheaper with a taproot-style system where you hit the=20 > common case often. This is another reason why P2MR is quite a loss > > > By eliminating depth-zero script trees, we'd force all P2MR users to pay= =20 > for the cost of having *at least* two spending conditions. We'd eliminate= =20 > the incentive for script devs to use P2MR over P2TR because both are=20 > equally efficient, and incentivize P2MR users to add a cooperative spendi= ng=20 > path using BIP340, since those users are already paying for the cost of= =20 > having a depth-1 tree anyway. > > This change to BIP360 wouldn't affect the recommended standard use-cases= =20 > for single-signer and multisig P2MR: hybrid addresses with one Schnorr le= af=20 > and one PQ leaf. If anything, this change would encourage the proper use = of=20 > PQ fallback scripts, because the incentive logic can be applied to someon= e=20 > who tries to use P2MR with only a single EC Schnorr leaf: This user must= =20 > pay for the cost of a second leaf script anyway, so why not follow=20 > best-practices and add a PQ leaf? > > AFAICT this change only affects use cases which would otherwise degrade= =20 > the fungibility of the UTXO set according to BIP360 critics, and encourag= es=20 > those use-cases to adopt a cooperative spending path which (assuming all= =20 > other factors equal) will be indistinguishable from a regular single-sign= er=20 > P2MR wallet with a PQ fallback leaf. > > I've already chatted about this off-list with some BIP360 proponents and= =20 > they seem receptive, but I'm really curious about the opinions of those w= ho=20 > are leaning towards P2TRv2. Would this change to BIP360 address your=20 > concerns surrounding P2MR's privacy incentives? If not, why? > > regards, > conduition > > > > --=20 > You received this message because you are subscribed to the Google Groups= =20 > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an= =20 > email to bitcoindev+...@googlegroups.com. > To view this discussion visit=20 > https://groups.google.com/d/msgid/bitcoindev/Q8YTY1ArMzia7tRvcZ5v769WPxCM= xAl_0rUy-byOBjBcTd4HXj7IB7Yt4gxLbKqk7EXFWy-PuGB6QtI28qRjE5Vob-l44UmBH6L8aXI= noSk%3D%40proton.me > . > > > > --=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/= 76e281e7-c4b4-4267-9bda-edfd2ee19dc0n%40googlegroups.com. ------=_Part_66049_813271033.1780768366965 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Conduition, Antonie, and list,

A reasonable= intersection of both opinions could be further witness discount of EC Schn= orr of P2MR (Segwit v2).=C2=A0
Further 2x witness discount (total 8x w= itness discount) makes P2MR EC-spend transaction cost almost at par with P2= TRv2 key-spend path.

Anyway, we will have to dis= cuss discount policy when we try to add PQ signature to Bitcoin. I think we= could discount witness for those who use EC Schnorr leaf if larger transac= tion cost heavily discourages the migration.

Bes= t Regards,
Hayashi
On Saturday, 6 June 2026 at 6:59:18=E2=80=AFam UTC+8 co= nduition wrote:
Hi= Antoine, thanks for the feedback. Glad to hear you're receptive!

It's important to consider that in any scenario where Bitcoin as we k= now it survives a CRQC, the vast majority of users would have had to migrat= e to an output type that includes an escape hatch long before we could have= been reasonably certain that a CRQC would materialize. Therefore we should= not assume that the vast majority of users strongly desire to migrate to a= n escape-hatch output type. (In fact, i think it would actually be reasonab= le to assume none have a strong desire to do so. This is because everyone h= as an incentive for everybody to migrate, but there is little incentive for= each individual to migrate if nobody else does.)

Therefore any additional barrier to encourage users to opt in= to an escape-hatch output type is working against CRQC risk mitigation.

All else being equal, whether we use P2MR or= P2TRv2 I believe we will end up with roughly the same (small) fraction of = the UTXO set migrated by Q-day. I believe this because address format adopt= ion is always slow even with good incentives. Even after 7 years and plenty= of incentives to migrate, P2TR still secures only a small fraction of the = UTXO-set compared to P2(W)PKH, and a tiny fraction (0.75%) of the supply.=C2=A0See=C2=A0this 2025 report from mempool.space=C2=A0and this 2025 report from Galaxy Digital. Incentivizing adoption doesn't always lead to adoption, so why = expect it to do so with P2TRv2? It doesn't offer any incentive over P2T= R beyond a shallow promise of maybe-some-day-quantum-security.
=

Here's my timeline prediction, with the above precedent in mind. W= e deploy a PQ output type, some minority of UTXOs migrate to it. When the f= irst confirmed ECDLP break is proven (e.g. if someone breaks a NUMS point) = or suspected (someone stole Satoshi's coins), then we will deploy a res= cue protocol which we hopefully prepared in advance to protect the majority= procrastinator UTXOs. Maybe we disable EC spending at the same time (a val= id option for either P2MR or P2TRv2).=C2=A0Then there will be a brief fork-= war (hard or soft) revolving around the question of how to handle Satoshi&#= 39;s coins. After that IDK what happens, but I expect Bitcoin will survive = if we prepare adequately today by deploying a quantum-safe address format a= nd PQ signature scheme, and develop rescue protocols for later activation t= o move laggards over to PQ wallets.

Whether we pick P2MR or P2TRv= 2 today, neither choice will affect the early stages of this plot-line very= much, so we might as well optimize for the long-term future, and P2MR wins= out there.

any additional barrier to encourage users to opt into an escape-hatch outp= ut type is working against CRQC risk mitigation. And i think the additional= costs of using P2MR compared to P2TRv2 is one of them.
=

I have good news for you: there is an optimization t= o BIP360 which would make single-signer Schnorr spending significantly (32 = bytes) cheaper. It's not my idea so I don't want to jump the gun in= explaining the details, but expect another mailing list post soon with mor= e info.

regards,
conduition
On Friday, June 5th, 2026 at 3:56 PM, Antoine Poinsot <daro...@protonmail.com> wrote:
Hi c= onduition,
=
I thin= k this would address the perverse incentive concern, but still fail in not = disincentivizing mass migration.

It's important to consider that in any scenario where B= itcoin as we know it survives a CRQC, the vast majority of users would have= had to migrate to an output type that includes an escape hatch long before= we could have been reasonably certain that a CRQC would materialize. There= fore we should not assume that the vast majority of users strongly desire t= o migrate to an escape-hatch output type. (In fact, i think it would actual= ly be reasonable to assume none have a strong desire to do so. This is beca= use everyone has an incentive for everybody to migrate, but there is little= incentive for each individual to migrate if nobody else does.)

Therefore any additional b= arrier to encourage users to opt into an escape-hatch output type is workin= g against CRQC risk mitigation. And i think the additional costs of using P= 2MR compared to P2TRv2 is one of them. Most likely all "long-tail"= ; users, who would be the least likely to seek migration, use single-key sp= ending policies. In fact, most Bitcoin users do: in the past 90 days of blo= cks, 93.6% of all transaction inputs are f= or single-key spending policies. For a typical 2-input 2-output transac= tion for a "single-key wallet", P2MR is about 15% more expensive = to use than P2TRv2 [^0].

I understand that P2MR does not introduce this additional cost just= for kicks, but i think "long-range" protection is a red-herring = and not worth hindering individual migration to the escape-hatch output typ= e, which is critical to the systemic migration of Bitcoin away from relying= on EC cryptography.

So your proposal does address one of my concerns with a P2MR + PQ opcod= e strategy. However, i still believe P2TRv2 to be a superior strategy for t= he reason outlined above.

Best,
Antoine

[^0]:= Using 57.5*2 + 43*2 =3D 201 vbytes as the base si= ze. P2MR adds an additional 32 witness bytes in the control block for the P= Q spend path, and an additional 35 witness bytes for the EC leaf script rev= eal. That's 33.5 more vbytes per input, which is 116.66% the size of th= e same transaction with P2TRv2.
On Wednesday, June 3rd, 2026 at 7:26 PM, 'conduition' via B= itcoin Development Mailing List <bitco...@googlegroups.com> wrote:
Hi l= ist. I'm following up on an idea I sketched in=C2=A0this thread debating P2MR vs P2TRv2.=C2=A0

The prem= ise is this: What if we modified this line of BIP360:

<= blockquote style=3D"border-left:3px solid rgb(200,200,200);border-top-color= :rgb(200,200,200);border-right-color:rgb(200,200,200);border-bottom-color:r= gb(200,200,200);padding-left:10px;color:rgb(102,102,102)">
The last sta= ck element is called the control block c, and must have length 1 + 32 * m, = for a value of m that is an integer between 0 and 128, inclusive. Fail if i= t does not have such a length.

To thi= s:

The last stack element is called the control block c, and must = have length 1 + 32 * m, for a value of m that is an integer between= =C2=A01=C2=A0and 128, inclusive. Fail if it does= not have such a length.

The key chan= ge is that the control block must now include at least one merkle authentic= ation path. This effectively bans depth-zero script trees in P2MR, and requ= ires every P2MR address to always pay the cost of having at least two spend= ing conditions.

This seems like a reduction = in P2MR's features and efficiency. Why would we want to ban depth-zero = script trees?=C2=A0Well these seem to be the source of a perverse in= centive, as pointed out by Matt Corallo and Antoine Poinsot in=C2=A0prior threads. Bitcoin sc= ript users are economically and practically incentivized by P2MR to use dep= th-zero script trees because their witnesses are smaller than if the= same script were used in a taproot script spend.

Furthermore, depending on the exact scripts and the d= evelopers' resources, devs using P2MR for a multi-party scripting proto= col may not be sufficiently incentivized to add a cooperative spending path= , even if their protocol might allow it. Doing so would require a depth-1 t= ree, which increases the witness size of the non-cooperative script spend p= ath by 32 bytes. For some short scripts, e.g <height> CLTV <= pubkey> CHECKSIG=E2=80=8B, the devs may actually have incentive <= i>not to add a cooperative spending path, because the cooperative path = would actually be less-efficient than just using the non-cooperative= path as the single leaf of a depth-zero tree.=C2=A0This leads to ea= sy fingerprinting of scripting protocols, less privacy for everyone else, a= nd undoes a key design goal of P2TR.

In=C2= =A0Matt's words:

The value=C2=A0of taproot is that its design nativ= ely adds [a cooperative spending path] *for free* to every contracting prot= ocol, and not only adds it for free but *forces* every contracting protocol= to carry at least some of the cost if they decline to do this. This result= s in a massive net privacy win across the entire Bitcoin=C2=A0ecosystem...<= /blockquote>
a goal of taproot is *privacy* while=C2=A0offering = efficiency for the common (all-sign) case. That is generally true across co= ntracting protocols and makes things net-cheaper with a taproot-style syste= m where you hit the common case=C2=A0often. This is another reason wh= y P2MR is quite a loss

By eliminating depth-zero script trees, we'd force all P2MR users to= pay for the cost of having at least two spending conditions. We'= ;d eliminate the incentive for script devs to use P2MR over P2TR because bo= th are equally efficient, and incentivize P2MR users to add a cooperative s= pending path using BIP340, since those users are already paying for the cos= t of having a depth-1 tree anyway.

Th= is change to BIP360 wouldn't affect the recommended standard use-cases = for single-signer and multisig P2MR: hybrid addresses with one Schnorr leaf= and one PQ leaf. If anything, this change would encourage the proper use o= f PQ fallback scripts, because the incentive logic can be applied to someon= e who tries to use P2MR with only a single EC Schnorr leaf: This user must = pay for the cost of a second leaf script anyway, so why not follow best-pra= ctices and add a PQ leaf?

AFAICT this chan= ge only affects use cases which would otherwise degrade the fungibility of = the UTXO set according to BIP360 critics, and encourages those use-cases to= adopt a cooperative spending path which (assuming all other factors equal)= will be indistinguishable from a regular single-signer P2MR wallet with a = PQ fallback leaf.

I've already chat= ted about this off-list with some BIP360 proponents and they seem receptive= , but I'm really curious about the opinions of those who are leaning to= wards P2TRv2. Would this change to BIP360 address your concerns surrounding= P2MR's privacy incentives? If not, why?

regar= ds,
conduition



--
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+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/Q8YTY= 1ArMzia7tRvcZ5v769WPxCMxAl_0rUy-byOBjBcTd4HXj7IB7Yt4gxLbKqk7EXFWy-PuGB6QtI2= 8qRjE5Vob-l44UmBH6L8aXInoSk%3D%40proton.me.


--
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/76e281e7-c4b4-4267-9bda-edfd2ee19dc0n%40googlegroups.com.
------=_Part_66049_813271033.1780768366965-- ------=_Part_66048_1323652623.1780768366965--