From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 05 Jun 2026 14:39:53 -0700 Received: from mail-oa1-f58.google.com ([209.85.160.58]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wVcGe-0005D2-0H for bitcoindev@gnusha.org; Fri, 05 Jun 2026 14:39:52 -0700 Received: by mail-oa1-f58.google.com with SMTP id 586e51a60fabf-44100eba7fbsf4188440fac.1 for ; Fri, 05 Jun 2026 14:39:51 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1780695586; cv=pass; d=google.com; s=arc-20240605; b=YvfOYZ6V4D/OUs184nboppivMi50b0cuagj6QO80+smW3pNB9PkYmF+P1hZbCV72Z3 b2yRpUNG2MPAkoFZhmbfNUtbL/IVxIXBcjmCLUGVuICzE7hzvfDkMt2REv4H/UF7RpI0 mFf0AE7oYaEyItGG10dyLbzqKBejn7IX0yDq9diwTwFsexEQkdPGjYIjlxqp0ydK5mJ4 8/9RXbcfeL/XAcwowLGPaLUExD4EA8xvEtxEsgXImn6qp3B07vUd54UOb/guRYC9fGcc Tyb5ehdFhe9y7LjhuaZ9UzXJ0f+VmjW1M+WodiU5i3YwwKreH3VejH2yi1BI+rE6dJ13 SMEw== 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=+2iMBd1tzoczjNTCBlJUHXPCkPA4cdtniYOlY1OfZzw=; fh=xD62l3wWkTch1aZ8EodvesWrDs4fz6Le1Oa3BoTgRr8=; b=PJRMPFlprkhGXLzYX0gIOwAmM3hCDaQgNlw6yORKq6NE0boOM2zEisQwgEv6NxvUKr AvzaI14SkVnd09bznf0YNF2QZx4tbn6TXfs+8x9pRzpJEYu5112KnvU3RWd7Sv0NuopU eacG9Rsr4UU/CNS0ep/4IH+Zl7uA5iRYyWQ1aQPdVgrU+1CAAUUxUj4rE5ahAbrXSYZj QGtd4xbCuqU0k3UjMyLoi61qWQQ5BlDSyDD7ZEexr3/ZAuhIQkry4+X+IYUT0ptoRQI+ lpUNGDIrWuCn8UV/TV6rGlegIpZaKGKV7jtXGFtuBDvJUJgwIf3bGFjSlkDKD7ZiesLP oFxA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=gY7wdqpd; spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.29 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=1780695586; x=1781300386; 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=+2iMBd1tzoczjNTCBlJUHXPCkPA4cdtniYOlY1OfZzw=; b=gu4cMeAC72QX183BiIWf4F3Db/f9nojX+o4rtgFcpdl9tomeK3fMivfHkjsLXEum2f GF8Zuo9nKfWXtDkkFG7nJ3qNeD3Gd/ZZ6Dpnz54tslTLcm9zGGP5O/VHJgbIPTuPq3Aw bDJMzGpyr3FJv30JDX+NOpRuHjU8FLnklNXO/DBJ4NRoSzeSgy2XHn1WWZcivc17bytU 18IA0Vfn/mRCqdDp3eogHCRN0yhSHU9JlckU8zc0iVEEx3UFHyNCGnpzrg/moaq3Gcpp VEJNC7nKgbz5Zl0+byH3rdJASOFOYchld7k8zcmp8D7prUNodWn6Ad4GR45rNKKXa5Rj +n5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780695586; x=1781300386; 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=+2iMBd1tzoczjNTCBlJUHXPCkPA4cdtniYOlY1OfZzw=; b=PCE3gwUprHru4IideOm2iGwz5ULMMABBZ2v0mOtZD33GO+s6MvSoMc2IFKMXpgFfN2 S3SNTk+rJSJ6xNYJyVxWAEq+pg7CuAK3NwizeDJUZZk2mleDvfYEHs+sLPkcRtGyl12f u9F4cuoMlobSQofPSI6GOIc7zsX1khuhEvfoN3CxKXD7t2R3UQ7OF56E4zBAKVa9Tb+4 7DcuBCU6NMQhCMLRIqL2usLyBLsYHcrgIIVYrenjA1NdjAYELDq/zZrf/CDKd8cUB+J+ FOzXn1paHFi4pkm4Xcwwqypa3jTM/KeOzvPx4DXVOJXD+u/abZ8vEtDN0SNy7OP4Us3a JEhw== X-Forwarded-Encrypted: i=2; AFNElJ9GKXqHa1Y0SNyNNRR7ID/2mLVZ19hC1KtG7Fs6XBLvTtP5wsN7sIW0gh0Ibtp8l5lFyP2590VkQtgZ@gnusha.org X-Gm-Message-State: AOJu0Yyp7ydbeZbEmtX5UnUvKgDeAQYa8bpWFjuuEg2Z7kFBg/7USKui NcFjKpMWSZqczxhv0k8yXVdlh4M57t06pVp7yS/0/skIW5gVRa7k91Pc X-Received: by 2002:a05:6870:f61c:b0:43e:5d18:e7e7 with SMTP id 586e51a60fabf-4413d854f5emr3097517fac.25.1780695585764; Fri, 05 Jun 2026 14:39:45 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUeH5whZVy8ve5FQpFKx4w/SDWFmtE2wMjTM6tyxcMe4aA==" Received: by 2002:a05:6871:408a:b0:43d:3481:db6e with SMTP id 586e51a60fabf-44109db6b20ls1824311fac.1.-pod-prod-01-us; Fri, 05 Jun 2026 14:39:40 -0700 (PDT) X-Received: by 2002:a05:6808:308a:b0:485:29d7:70a9 with SMTP id 5614622812f47-4868e0428bcmr3386023b6e.41.1780695580618; Fri, 05 Jun 2026 14:39:40 -0700 (PDT) Received: by 2002:a7b:ce06:0:b0:488:963a:630a with SMTP id 5b1f17b1804b1-490c25f2483ms5e9; Fri, 5 Jun 2026 12:56:43 -0700 (PDT) X-Received: by 2002:a05:600c:46ca:b0:485:9a50:3370 with SMTP id 5b1f17b1804b1-490c25a7f8amr85585605e9.8.1780689401634; Fri, 05 Jun 2026 12:56:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1780689401; cv=none; d=google.com; s=arc-20240605; b=Np21zRr1rJQyTHcHDKrQAhYXqdFsjdfYHGS9caDtuw6rKRVT8rQUUVw5o/hUb642Fm NoTB0F15as0y3ce1AI6vYaUVT2xaQ0hsm5d9Pngxw6uOqHMvtBmRFvpscYW2Rq2bo9p2 scSTULpAVdJDjZIRqQggpB3L6cr/oGMyF2nj7ndAJWBh3lmXvATi1Ml1bUxKiKyjP9jg px0EttDld4eyDOJFDjCL4BjmPip42oTVwGAsVYliGNoIC4HreVH4oCRBbVuW5q0YT14g VififW4a2Xuk4G9ceKiQhthKqqN6rKA9LdjanjbBm1gyP4kPa7Gu05gd/H8oMbThkB32 muww== 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=Ex188Lgu/5XiHdcposHlJMZcW+wnFd3cGQe3KvS8V1M=; fh=NdMtxlgcB7XMNm7RkllsTejKYwjjd2EPyy2sAVEi5wE=; b=ZUmkCa4zjPWISCcyFQGSkf6GYapIhIC90g5Vkz0zd3wib/n/iGT1/3sZL08babSeYq iof9Lnw0hGK3xmsCJWGVACoY05NFHmKcfw82xynhmNn7lHt1ln2DrEv+WFxM18fpi2M/ wIaGHMgyxDXlXaaEbHjkqgFVmkpIalzlmoMZ2MKo078TqqyuKNqRp+O4TVqBVoBeUomJ ykvAyV+sczvk4MuZGMXewyEeN5GMSAVuS66h1vaNbO1WHKMLEX6UCFUEEZQzqOILgcaz hjrpEBCEETYoDLnxsxKWQw4L/tw5J1yEemlThQbiQza+EA704ncID9KWQQYTd9h5Fc1Q epLg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=gY7wdqpd; spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.29 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-10629.protonmail.ch (mail-10629.protonmail.ch. [79.135.106.29]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-490c2d30be3si375165e9.1.2026.06.05.12.56.41 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Jun 2026 12:56:41 -0700 (PDT) Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 79.135.106.29 as permitted sender) client-ip=79.135.106.29; Date: Fri, 05 Jun 2026 19:56:34 +0000 To: conduition From: "'Antoine Poinsot' via Bitcoin Development Mailing List" Cc: "bitcoindev@googlegroups.com" Subject: Re: [bitcoindev] Aligning privacy incentives in P2MR Message-ID: In-Reply-To: References: Feedback-ID: 7060259:user:proton X-Pm-Message-ID: c7c3dd58c2570b2a9113065cc2cb7816e26a6841 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_PcuaVx6XjcQBLlzVlTQ7bNmlpP1eiGrrrZfyi7Ik" 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=gY7wdqpd; spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.29 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=_PcuaVx6XjcQBLlzVlTQ7bNmlpP1eiGrrrZfyi7Ik Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi conduition, I think this would address the perverse incentive concern, but still fail i= n not disincentivizing mass migration. It's important to consider that in any scenario where Bitcoin as we know it= survives a CRQC, the vast majority of users would have had to migrate to a= n output type that includes an escape hatch long before we could have been = reasonably certain that a CRQC would materialize. Therefore we should not a= ssume that the vast majority of users strongly desire to migrate to an esca= pe-hatch output type. (In fact, i think it would actually be reasonable to = assume none have a strong desire to do so. This is because 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 barrier to encourage users to opt into an escape-h= atch output type is working against CRQC risk mitigation. And i think the a= dditional costs of using P2MR compared to P2TRv2 is one of them. Most likel= y all "long-tail" users, who would be the least likely to seek migration, u= se single-key spending policies. In fact, most Bitcoin users do: in the pas= t 90 days of blocks, [93.6% of all transaction inputs are for single-key sp= ending policies](https://mainnet.observer/charts/inputs-types-by-count/). F= or a typical 2-input 2-output transaction for a "single-key wallet", P2MR i= s about 15% more expensive to use than P2TRv2 [^0]. I understand that P2MR does not introduce this additional cost just for kic= ks, but i think "long-range" protection is a red-herring and not worth hind= ering individual migration to the escape-hatch output type, which is critic= al to the systemic migration of Bitcoin away from relying on EC cryptograph= y. So your proposal does address one of my concerns with a P2MR + PQ opcode st= rategy. However, i still believe P2TRv2 to be a superior strategy for the r= eason outlined above. Best, Antoine [^0]: Using [57.5*2 + 43*2](https://bitcoin.stackexchange.com/a/75124/10149= 8) =3D 201 vbytes as the base size. P2MR adds an additional 32 witness byte= s in the control block for the PQ spend path, and an additional 35 witness = bytes for the EC leaf script reveal. That's 33.5 more vbytes per input, whi= ch is 116.66% the size of the same transaction with P2TRv2. On Wednesday, June 3rd, 2026 at 7:26 PM, 'conduition' via Bitcoin Developme= nt Mailing List wrote: > Hi list. I'm following up on an idea I sketched in[this thread debating P= 2MR vs P2TRv2](https://groups.google.com/g/bitcoindev/c/Qy4gwAGTK2w). > > 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 leng= th 1 + 32 * m, for a value of m that is an integer between 0 and 128, inclu= sive. Fail if it does not have such a length. > > To this: > >> The last stack element is called the control block c, and must have leng= th 1 + 32 * m, for a value of m that is an integer between1and 128, inclusi= ve. Fail if it does not have such a length. > > The key change is that the control block must now include at least one me= rkle authentication path. This effectively bans depth-zero script trees in = P2MR, and requires every P2MR address to always pay the cost of having at l= east two spending conditions. > > This seems like a reduction in P2MR's features and efficiency. Why would = we want to ban depth-zero script trees? Well these seem to be the source of= a perverse incentive, as pointed out by Matt Corallo and Antoine Poinsot i= n [prior threads](https://groups.google.com/g/bitcoindev/c/JA3kDl8AmQg). Bi= tcoin script users are economically and practically incentivized by P2MR to= use depth-zero script trees because their witnesses are smaller than if th= e same script were used in a taproot script spend. > > Furthermore, depending on the exact scripts and the developers' resources= , devs using P2MR for a multi-party scripting protocol may not be sufficien= tly incentivized to add a cooperative spending path, even if their protocol= might allow it. Doing so would require a depth-1 tree, which increases the= witness size of the non-cooperative script spend path by 32 bytes. For som= e short scripts, e.g CLTV CHECKSIG=E2=80=8B, the devs may= actually have incentive not to add a cooperative spending path, because th= e cooperative path would actually be less-efficient than just using the non= -cooperative path as the single leaf of a depth-zero tree. This leads to ea= sy fingerprinting of scripting protocols, less privacy for everyone else, a= nd undoes a key design goal of P2TR. > > In[Matt's words](https://groups.google.com/g/bitcoindev/c/JA3kDl8AmQg/m/E= WS5ZxqZAAAJ): > >> The value of taproot is that its design natively adds [a cooperative spe= nding path] *for free* to every contracting protocol, 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 results in a massive net privacy = win across the entire Bitcoin ecosystem... > >> a goal of taproot is *privacy* while offering efficiency for the common = (all-sign) case. That is generally true across contracting protocols and ma= kes things net-cheaper with a taproot-style system where you hit the 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 = for the cost of having at least two spending conditions. We'd eliminate the= incentive for script devs to use P2MR over P2TR because both are equally e= fficient, and incentivize P2MR users to add a cooperative spending path usi= ng BIP340, since those users are already paying for the cost of having a de= pth-1 tree anyway. > > This 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 change only affects use cases which would otherwise degrade t= he fungibility of the UTXO set according to BIP360 critics, and encourages = those use-cases to adopt a cooperative spending path which (assuming all ot= her factors equal) will be indistinguishable from a regular single-signer P= 2MR wallet with a PQ fallback leaf. > > I've already chatted 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 towards P2TRv2. Would this change to BIP360 address your conce= rns surrounding P2MR's privacy incentives? If not, why? > > regards, > conduition > > -- > 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/Q8YTY1ArMzia7tRvcZ5v769WPxCMxAl_0rUy-byOBjBcTd4HXj7IB7Yt4gxLbKqk7EXFWy-Pu= GB6QtI28qRjE5Vob-l44UmBH6L8aXInoSk%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/= xDZdaNASwweJSIjFLVJidZYfsMsle8RuX0G74BWggmIBRZaMgUaPjJLtj5s6BRNr1XObrie1JV7= dQ8w6h9h_hyBPOEnydBc2F9kCsEmDE80%3D%40protonmail.com. --b1=_PcuaVx6XjcQBLlzVlTQ7bNmlpP1eiGrrrZfyi7Ik Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi conduiti= on,
I t= hink this would address the perverse incentive concern, but still fail in n= ot disincentivizing mass migration.

It's important to consider that in any scenari= o where Bitcoin as we know it survives a CRQC, the vast majority of users w= ould have had to migrate to an output type that includes an escape hatch lo= ng before we could have been reasonably certain that a CRQC would materiali= ze. Therefore we should not assume that the vast majority of users strongly= desire to migrate to an escape-hatch output type. (In fact, i think it wou= ld actually be reasonable to assume none have a strong desire to do so. Thi= s is because 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 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. Most likely all "lo= ng-tail" users, who would be the least likely to seek migration, use single= -key spending policies. In fact, most Bitcoin users do: in the past 90 days= of blocks, 93.6% of all transaction = inputs are for single-key spending policies. For a typical 2-input 2-ou= tput transaction for a "single-key wallet", P2MR is about 15% more expensiv= e to use than P2TRv2 [^0].

I understand that P2MR does not introduce this addition= al cost just for kicks, but i think "long-range" protection is a red-herrin= g and not worth hindering individual migration to the escape-hatch output t= ype, which is critical to the systemic migration of Bitcoin away from relyi= ng on EC cryptography.

So your proposal does address one of my concerns with a P2M= R + PQ opcode strategy. However, i still believe P2TRv2 to be a superior st= rategy for the reason outlined above.

Best,
Antoine

[^0]: Using 57.5*2 + 43*2 =3D 201 vbytes as the base size. P2MR adds an additional= 32 witness bytes in the control block for the PQ spend path, and an additi= onal 35 witness bytes for the EC leaf script reveal. That's 33.5 more vbyte= s per input, which is 116.66% the size of the same transaction with P2TRv2.=
On Wednesday, June 3rd, 2026 at 7:26 PM, 'conduition' via Bitcoin D= evelopment Mailing List <bitcoindev@googlegroups.com> wrote:
Hi list. I'm following up on an idea I sketched in this thread debating P2MR vs P2TRv2. 
<= br>
The premise is this: What if we modified this line of BIP360:=

The last stack element is called the contro= l block c, and must have length 1 + 32 * m, for a value of m that is an int= eger between 0 and 128, inclusive. Fail if it does not have such a length.<= /div>

To this:

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

The key change is that = the control block must now include at least one merkle authentication path.= This effectively bans depth-zero script trees in P2MR, and requires every = P2MR address to always pay the cost of having at least two spending conditi= ons.

This seems like a reduction in P2MR's f= eatures and efficiency. Why would we want to ban depth-zero script trees?&n= bsp;Well these seem to be the source of a perverse incentive, as poi= nted out by Matt Corallo and Antoine Poinsot in prior threads. Bitcoin= script users are economically and practically incentivized by P2MR to use = depth-zero script trees because their witnesses are smaller than if = the same script were used in a taproot script spend.
<= div>
Furthermore, depending on the exact scripts and th= e developers' resources, devs using P2MR for a multi-party scripting protoc= ol 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 tr= ee, which increases the witness size of the non-cooperative script spend pa= th by 32 bytes. For some short scripts, e.g <height> CLTV <p= ubkey> CHECKSIG=E2=80=8B, the devs may actually have incentive not to add a cooperative spending path, because the cooperative path w= ould actually be less-efficient than just using the non-cooperative = path as the single leaf of a depth-zero tree. This leads to eas= y fingerprinting of scripting protocols, less privacy for everyone else, an= d undoes a key design goal of P2TR.

In Matt's words:

The value of taproot is that its= design natively adds [a cooperative spending path] *for free* to every con= tracting protocol, and not only adds it for free but *forces* every contrac= ting protocol to carry at least some of the cost if they decline to do this= . This results in a massive net privacy win across the entire Bitcoin = ecosystem...

a goal of taproot is *p= rivacy* while offering efficiency for the common (all-sign) cas= e. That is generally true across contracting protocols and makes things net= -cheaper with a taproot-style system where you hit the common case often. This is another reason why P2MR is quite a loss
<= /blockquote>

By eliminating depth-zero script tree= s, 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 us= e P2MR over P2TR because both are equally efficient, and incentivize P2MR u= sers to add a cooperative spending path using BIP340, since those users are= already paying for the cost of having a depth-1 tree anyway.
<= div>
This change to BIP360 wouldn't affect the recommen= ded standard use-cases for single-signer and multisig P2MR: hybrid addresse= s with one Schnorr leaf and one PQ leaf. If anything, this change would enc= ourage the proper use of PQ fallback scripts, because the incentive logic c= an be applied to someone who tries to use P2MR with only a single EC Schnor= r leaf: This user must pay for the cost of a second leaf script anyway, so = why not follow best-practices and add a PQ leaf?

AFAICT this change only affects use cases which would otherwise degr= ade the fungibility of the UTXO set according to BIP360 critics, and encour= ages those use-cases to adopt a cooperative spending path which (assuming a= ll other factors equal) will be indistinguishable from a regular single-sig= ner P2MR wallet with a PQ fallback leaf.

I've already chatted 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 towards P2TRv2. Would this change to BIP360 address your conce= rns surrounding P2MR's privacy incentives? If not, why?

regards,
conduition



--
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+u= nsubscribe@googlegroups.com.
To view this discussion visit h= ttps://groups.google.com/d/msgid/bitcoindev/Q8YTY1ArMzia7tRvcZ5v769WPxCMxAl= _0rUy-byOBjBcTd4HXj7IB7Yt4gxLbKqk7EXFWy-PuGB6QtI28qRjE5Vob-l44UmBH6L8aXInoS= k%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/bitcoindev/= xDZdaNASwweJSIjFLVJidZYfsMsle8RuX0G74BWggmIBRZaMgUaPjJLtj5s6BRNr1XObrie1JV7= dQ8w6h9h_hyBPOEnydBc2F9kCsEmDE80%3D%40protonmail.com.
--b1=_PcuaVx6XjcQBLlzVlTQ7bNmlpP1eiGrrrZfyi7Ik--