From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 13 Jun 2026 08:36:05 -0700 Received: from mail-oo1-f60.google.com ([209.85.161.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wYQOy-0002kM-HS for bitcoindev@gnusha.org; Sat, 13 Jun 2026 08:36:05 -0700 Received: by mail-oo1-f60.google.com with SMTP id 006d021491bc7-69e78907328sf2687811eaf.2 for ; Sat, 13 Jun 2026 08:36:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1781364958; x=1781969758; 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=3fiJdMf2Mk0Kbk9uQq1xCX9U2YsJPu6+dYnxON+w1FM=; b=WFJK6LEu7KJ1PUA8LdvhFuj0oofPZ25epsqR3QHmE+oVIilDFDUpDrdw2fCRhdXM/X AE1NQq+hQv2gpEhYfdyYhyKdXFFZ4CZmHr5CUMgGKTyfZBoQpT9FoH1UAlq1zUgSh8TB foM1qQpXtEWpX2nk79p0zEigPzrN+zIH00/5p35qEcvwk1/VrrVMrgwssUEh7I9CTd3h do2wepcVVAR9EmMpo4VsykcicL7l9XaEBba97JI79r0tRX/WX3zzJ9Poz+KuIN14Jhn8 nZZB/e5WkzgYCEmTFzAv+eIO0qKXCUF8L4Su2FxJ0bdTW05hBWiTtFQluq3McUqWnRcl okLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781364958; x=1781969758; 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=3fiJdMf2Mk0Kbk9uQq1xCX9U2YsJPu6+dYnxON+w1FM=; b=s6tSdbLT1fxU2n7dKH7LuMiLKBnggsW8uWWBwZ/TRidqoe16ogBv0MS7Z+D5xbUTiL 5SNOsnDthiTGDKtMOhqh6dyHjpoXttdkqp4XyjTfBodKW+c86aXSJ60nGjK0wnzbnclE /ooZ+Y2MBbGAI4YQqwFQxVEtcvsBcHoCf+1gegNkxr9C2bkSYOEiwUnxktjFio4VWVau lIsDt2e0oSnEbtxd5RQiBWQ6RH6l6My1seuc8ZUMD6znO4YcoTMUyiEoLX3qEDPXqOGN UjS2T/y/ddJsYjKTQEPY2NkXLrbkUrDnQYzvHi5K813tz9avjrx/addBx2ltOMb2/+mA nLBw== X-Forwarded-Encrypted: i=1; AFNElJ/dU39UQV0WzvHTtzHuUf/Fk//1kUF8NipuCe1RH4I8YmU0VNkpz56M7NUllyZ0K1Hlr0ttKsgc6/dp@gnusha.org X-Gm-Message-State: AOJu0YxAvFFgux2O7HuBqYhB67YMtXn406E8z4xFTEYBeujPJ7MKbKGa bnPKJI+/vbTvg+U9zAaqxewA3tgxGYJuQJoIFCQfSyf4IqFGVvbjnrGD X-Received: by 2002:a05:6820:c452:10b0:69e:e019:a187 with SMTP id 006d021491bc7-69ee019a58amr2457676eaf.20.1781364958265; Sat, 13 Jun 2026 08:35:58 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUddLBTI/Pp4S9c4Q2YqJ9+CLDx+t7vBiFVTi6B0QY09cQ==" Received: by 2002:a05:6871:9f0e:b0:440:dc16:6d79 with SMTP id 586e51a60fabf-442617d23e5ls860255fac.0.-pod-prod-07-us; Sat, 13 Jun 2026 08:35:53 -0700 (PDT) X-Received: by 2002:a05:6808:f16:b0:486:560d:aa8b with SMTP id 5614622812f47-4872f565ecdmr4628687b6e.26.1781364952961; Sat, 13 Jun 2026 08:35:52 -0700 (PDT) Received: by 2002:a05:690c:e245:10b0:7ba:f1b3:9504 with SMTP id 00721157ae682-7f798675cadms7b3; Sat, 13 Jun 2026 08:33:30 -0700 (PDT) X-Received: by 2002:a05:690c:e3ce:b0:7b9:39f:62c8 with SMTP id 00721157ae682-7f7b7d32bf7mr75808747b3.27.1781364810148; Sat, 13 Jun 2026 08:33:30 -0700 (PDT) Date: Sat, 13 Jun 2026 08:33:29 -0700 (PDT) From: "'conduition' via Bitcoin Development Mailing List" To: Bitcoin Development Mailing List Message-Id: <5cab6e7c-bd9f-4098-a1b5-e6218f1f1cc7n@googlegroups.com> In-Reply-To: References: Subject: [bitcoindev] Re: Aligning privacy incentives in P2MR MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_246168_2017664211.1781364809674" X-Original-Sender: conduition@proton.me X-Original-From: conduition Reply-To: conduition 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 (-) ------=_Part_246168_2017664211.1781364809674 Content-Type: multipart/alternative; boundary="----=_Part_246169_424805705.1781364809674" ------=_Part_246169_424805705.1781364809674 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I have just submitted a PR into BIP360 which implements the suggestion=20 described in OP . regards, conduition On Wednesday, June 3, 2026 at 7:26:39=E2=80=AFPM UTC-4 conduition 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 "= 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/= 5cab6e7c-bd9f-4098-a1b5-e6218f1f1cc7n%40googlegroups.com. ------=_Part_246169_424805705.1781364809674 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

regards,
conduition

<= /div>



On Wednesday, June 3, 2026 at 7:2= 6:39=E2=80=AFPM UTC-4 conduition wrote:
Hi list. I'm following up on an idea I sketched in=C2= =A0this thread debating P2MR vs P2TRv2.=C2=A0

<= div>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 length = 1 + 32 * m, for a value of m that is an integer between 0 and 128, inclusiv= e. Fail if it does not have such a length.

To this:

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 bet= ween=C2=A01=C2=A0and 128, inclusive. Fail = if it does not have such a length.

Th= e 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 conditions.

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

Furthermore, depending on the exact scripts and the developers&= #39; resources, devs using P2MR for a multi-party scripting protocol may no= t be sufficiently 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 some short scripts, e.g <height> CLTV <pubkey>= CHECKSIG=E2=80=8B, the devs may actually have incentive not = to add a cooperative spending path, because the cooperative path would actu= ally be less-efficient than just using the non-cooperative path as t= he single leaf of a depth-zero tree.=C2=A0This leads to easy fingerp= rinting of scripting protocols, less privacy for everyone else, and undoes = a key design goal of P2TR.

In=C2=A0Matt's words:

The value=C2=A0of taproot is that its design natively adds [a cooperative spending pat= h] *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 acros= s the entire Bitcoin=C2=A0ecosystem...

a goal of taproot i= s *privacy* while=C2=A0offering efficiency for the common (all-sign)= case. That is generally true across contracting protocols and makes things= net-cheaper with a taproot-style system where you hit the common case=C2= =A0often. This is another reason why P2MR is quite a loss
<= /div>

By eliminating depth-zero scrip= t 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 scr= ipt devs to use P2MR over P2TR because both are equally efficient, and ince= ntivize P2MR users to add a cooperative spending path using BIP340, since t= hose users are already paying for the cost of having a depth-1 tree anyway.=

This change to BIP360 wouldn't a= ffect the recommended standard use-cases for single-signer and multisig P2M= R: hybrid addresses with one Schnorr leaf and one PQ leaf. If anything, thi= s change would encourage the proper use of PQ fallback scripts, because the= incentive logic can be applied to someone 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-practices and add a PQ leaf?

AFAICT this change only affects use cases which wo= uld otherwise degrade the fungibility of the UTXO set according to BIP360 c= ritics, 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 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 concerns surrounding P2MR's privacy incentives? If= not, why?

regards,
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 bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/5cab6e7c-bd9f-4098-a1b5-e6218f1f1cc7n%40googlegroups.com.
------=_Part_246169_424805705.1781364809674-- ------=_Part_246168_2017664211.1781364809674--