From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 05 Jun 2026 15:59:27 -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 1wVdVd-0005gZ-Km for bitcoindev@gnusha.org; Fri, 05 Jun 2026 15:59:27 -0700 Received: by mail-oa1-f59.google.com with SMTP id 586e51a60fabf-43d1e8bbb82sf4646321fac.2 for ; Fri, 05 Jun 2026 15:59:25 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1780700359; cv=pass; d=google.com; s=arc-20240605; b=MwfaNXRyyG96JyZsvN70uOMioGPAtb6tKYR7E4pSuhwBs17qf1CPu/w2LNJxI0BoWt WVri0vVNzeTQ1OuE0t31jEAbsqeywBN0Vijr/I/MzjXdcqRUA+Hzc5ZKK97NVSBbRb+o QdhsTEWkf2tOqXtPYLTyOrRvROqTTkmXB6u14FmPEPmRBV9XdbyZRJUELKyOeJs+HIGF hkoouKvRqj6oDonGuUdqX9bwkl587QcrYI8+dh/8RqC3q1V1M+OJdgDrvQsMU4twmp/G loNerZ8c3ebsPEUwa3i7yVGJ3lmYHL/QFRu5q65XiwLTMzNGKb8knIBgcd/hHGA1/bIO 6GAw== 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=xhLPqunqr6hBHMhue5gf64X7Vrq9GDK/3EeJFAPM0Qw=; fh=p0Ql+wBFr+x9gZ9wLPYKbQ7FuhmgN0fHilvgsVoEyJU=; b=aQaW/pUGR9pLwsj6SvgifLnHWDuk02kykTSKimW1IlLBs2fnuW59x+DhqowmEbZ03n HoW/y/gcRkhV87PRNLBSV2LRSq03EB8jaSdkvna0NoBe5jOBmChdJP9hRehRSgc09+e8 bXeuvLbjO9lxLbDelqW7sMt4PHiBGri9vaHvnmryCcic3v4qE2K+2wIESB6V+eBg0Hsy AxiG+FcA4yk9YpwWghX//e70V3E0Yopsy7XBkOAGN8VtgceruRO11lgSMT+upJGI0aoJ YFVQ3O5ab7AS4FcxP6roITFD/66TvTxjk066N+2gbPojMV2+X58uys+MCDxjy5HEa05L T4SA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=GHMW97Ky; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.24 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1780700359; x=1781305159; 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=xhLPqunqr6hBHMhue5gf64X7Vrq9GDK/3EeJFAPM0Qw=; b=fGjRvSt5PucwPVuoi6vVcA1Xjn2Gj/sSi4dGPfw7TUaemvWi82WjhD4T8KDTOblh1I HN4fBfNLP0r1CxZ68UlhCEsBd0N04+fAY/J26PcZN5oux/L/gbgkyltVFAcsxKg4hw8m m/joKuDpCY/+sFlRsmvq+IcLhfuVwXwAYpa1pTjkn19r3XTgAbRpLuH2kP2aS2ga1/mM Tc40GOgDYZLltw1kBAwPvlbgFW3gSRrfXNjUuZ7mnFeZMOdjexfGzMnqhIWwfqRSonYS SUcXbu+UiEcVDGCa5/fMu095ljG0Nx1CGqFltvgBGy/opCY064KAXbEDLK+actesU2ot zmmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780700359; x=1781305159; 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=xhLPqunqr6hBHMhue5gf64X7Vrq9GDK/3EeJFAPM0Qw=; b=JVkHoCP0QFFvwIgE7g2U3RJaUhMjXn0o3Jzl1rSEXodM+BDNFYpQOoDCZ4bYhxi+fo OFy1LKprRlmFW8cFn5cgJ0qgtT6wEOPiK9ZYA30nmO1tasiG85FbO8nvAAwJFJIQGMFI iT3UnTeho3G/x9Vh4FU6+ES4+MW/k33131KuQ5J/9BuoGev1O4RMkuGlAyne/8HSKOiK PQtRGphrW+gvNEIX7qKTmEYDAlMIiQzWAu7NLMRarDNNFvkrEEWFCxEqniHZQw8keU+5 zyUBlpV7YR0vhPnIUsy7ITwZdD23ZlBOfyoNd7u+mx26JPlFT5eWidmA0ZQmOW5F/G9N BQBg== X-Forwarded-Encrypted: i=2; AFNElJ+Mchg8Vqshi4Xfrq1WoFuvEl/a7K8ThxqYVq/dHBTdnHTeAJvNMLA/6ChDMJe+de6TlFo1ZXyehYj0@gnusha.org X-Gm-Message-State: AOJu0YwGY/Egndzb1W+VUBWFqkqYFysasbLs9K8MdS9tyNdoRdNH+Z7j YVERazJR99O14so9NhQMWL2HWbjNjmnvt9Oxv40In4ouo3XIi9KfWoc6 X-Received: by 2002:a05:6870:d8c9:b0:43d:3b4b:e37b with SMTP id 586e51a60fabf-4413dbd076cmr3076689fac.29.1780700358882; Fri, 05 Jun 2026 15:59:18 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUc2yJNRM7G5oFhhe36TxOIC1r5ZgTaIAbIj+cKaisVVMg==" Received: by 2002:a05:6870:b49f:b0:441:4757:d522 with SMTP id 586e51a60fabf-441475810a7ls888431fac.0.-pod-prod-09-us; Fri, 05 Jun 2026 15:59:13 -0700 (PDT) X-Received: by 2002:a05:6808:c227:b0:485:4443:dbed with SMTP id 5614622812f47-4868dbf7a46mr3825895b6e.8.1780700353305; Fri, 05 Jun 2026 15:59:13 -0700 (PDT) Received: by 2002:a05:6809:11:10b0:480:77ce:ad79 with SMTP id 5614622812f47-4868f468ab0msb6e; Fri, 5 Jun 2026 15:52:09 -0700 (PDT) X-Received: by 2002:a05:6808:d4d:b0:485:4601:9c84 with SMTP id 5614622812f47-4868de44d92mr3366291b6e.29.1780699929332; Fri, 05 Jun 2026 15:52:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1780699929; cv=none; d=google.com; s=arc-20240605; b=iEQNA5xnzEnQS8YyDVb5bNguUECg0uxUuOM2Pez1CMsdZRjD4RAUcOUY5+N13LbQKF fZCdDEZ03AW0XaMjihsRqcNZTbSyf/jIw/RdM/Sk1EEjZH5nWLvJUM3gFJ6H1cyy+UFl itWN1kk1FVpWlaTFNEv8hDaP9Pbn1/SvfZxtE1pywxQx/Fvt1kmJ3lY3onc5zjhtdkAj kaHXY2qYJoEDTFdtbKtemu/tOduqRk+ZvqENDss7YHv7LczHXktx/JNzcZeOa+pCHhp9 sstFfQ1M6n9KrvnW75sjdRumQ3A0V1Kk0/h35tdu0UPP1RO+UHURW0CJedck/mu7LdCV 7dMw== 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=CYkLqilqylZPZWfQwD1bBQz0TT/sUvWnh1mJNBKj3Nw=; fh=Jm/QMpT/wvPQlcrWqwPAcT6blQ3uqhuWNdm4VS1a/gg=; b=kEe1c6lXx0qdXx8yxx/EDxTmFhXfBPK2BD9SeoS3ZBaaPdfIGsDRgySY52jde8qM2K FTU+HSNDBY09m3sWWGWr00y2Bzhgm5mPVMXOr1Ci98OzSJFiDMgdXuuYs0Pq0sgQkk8p GTLYVwH2wIRHzH0sNSMsBR9oPAdqclVLr+nvf+fEnRrKxJnxqik7KrGUjsi3XDgJ7A4k JOt8gs/zhVjlDnMyaiajpvBJxokET8XBbfSBsALzkZRrLtWdNsmPcN3MD2JqL+V6/TOO 3++lcpa+8pCJ6ALcPb+0ZPD34okXkfMX8NdR+lKWBkpaH6gRFUnpeVtY0BRq8SLXx5s4 0kPg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=GHMW97Ky; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.24 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-24424.protonmail.ch (mail-24424.protonmail.ch. [109.224.244.24]) by gmr-mx.google.com with ESMTPS id 586e51a60fabf-44125d73d74si181655fac.8.2026.06.05.15.52.08 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Jun 2026 15:52:09 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 109.224.244.24 as permitted sender) client-ip=109.224.244.24; Date: Fri, 05 Jun 2026 22:52:00 +0000 To: Antoine Poinsot From: "'conduition' 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: 72003692:user:proton X-Pm-Message-ID: 44f45424e9359489194bc0e6fb679d131b981cdb MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------0dbd1793f244bd8717f9d69008c9b2b0c305585340d1e9e16b49630cc30817a8"; charset=utf-8 X-Original-Sender: conduition@proton.me X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=GHMW97Ky; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.24 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=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 (-) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------0dbd1793f244bd8717f9d69008c9b2b0c305585340d1e9e16b49630cc30817a8 Content-Type: multipart/mixed;boundary=---------------------697354900f4283bac5c210961b82352c -----------------------697354900f4283bac5c210961b82352c Content-Type: multipart/alternative;boundary=---------------------6da062a6b2ca5554c711666b99d78dd4 -----------------------6da062a6b2ca5554c711666b99d78dd4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" 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 = 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 bee= n reasonably certain that a CRQC would materialize. Therefore we should not= assume that the vast majority of users strongly desire to migrate to an es= cape-hatch output type. (In fact, i think it would actually be reasonable t= o assume none have a strong desire to do so. This is because everyone has a= n incentive for everybody to migrate, but there is little incentive for eac= h individual to migrate if nobody else does.) >=20 >=20 > Therefore any additional barrier to encourage users to opt into 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 u= p with roughly the same (small) fraction of the UTXO set migrated by Q-day.= I believe this because address format adoption is always slow even with go= od 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 f= rom mempool.space=C2=A0and this 2025 report from Galaxy Digital. Incentiviz= ing adoption doesn't always lead to adoption, so why expect it to do so wit= h P2TRv2? It doesn't offer any incentive over P2TR beyond a shallow promise= of maybe-some-day-quantum-security. Here's my timeline prediction, with the above precedent in mind. We deploy = a PQ output type, some minority of UTXOs migrate to it. When the first conf= irmed ECDLP break is proven (e.g. if someone breaks a NUMS point) or suspec= ted (someone stole Satoshi's coins), then we will deploy a rescue protocol = which we hopefully prepared in advance to protect the majority procrastinat= or UTXOs. Maybe we disable EC spending at the same time (a valid 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's coins. After= that IDK what happens, but I expect Bitcoin will survive if we prepare ade= quately today by deploying a quantum-safe address format and PQ signature s= cheme, and develop rescue protocols for later activation to move laggards o= ver to PQ wallets. Whether we pick P2MR or P2TRv2 today, neither choice will affect the early = stages of this plot-line very much, so we might as well optimize for the lo= ng-term future, and P2MR wins out there. > any additional barrier to encourage users to opt into an escape-hatch out= put type is working against CRQC risk mitigation. And i think the additiona= l 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 ma= ke single-signer Schnorr spending significantly (32 bytes) cheaper. It's no= t my idea so I don't want to jump the gun in explaining the details, but ex= pect another mailing list post soon with more info. regards, conduition On Friday, June 5th, 2026 at 3:56 PM, Antoine Poinsot wrote: > Hi conduition, >=20 > I think this would address the perverse incentive concern, but still fail= in not disincentivizing mass migration. >=20 > 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= an output type that includes an escape hatch long before we could have bee= n reasonably certain that a CRQC would materialize. Therefore we should not= assume that the vast majority of users strongly desire to migrate to an es= cape-hatch output type. (In fact, i think it would actually be reasonable t= o assume none have a strong desire to do so. This is because everyone has a= n incentive for everybody to migrate, but there is little incentive for eac= h individual to migrate if nobody else does.) >=20 > Therefore any additional barrier to encourage users to opt into an escape= -hatch output type is working against CRQC risk mitigation. And i think the= additional costs of using P2MR compared to P2TRv2 is one of them. Most lik= ely all "long-tail" users, who would be the least likely to seek migration,= use single-key spending policies. In fact, most Bitcoin users do: in the p= ast 90 days of blocks, 93.6% of all transaction inputs are for single-key s= pending policies. For a typical 2-input 2-output transaction for a "single-= key wallet", P2MR is about 15% more expensive to use than P2TRv2 [^0]. >=20 > I understand that P2MR does not introduce this additional cost just for k= icks, but i think "long-range" protection is a red-herring and not worth hi= ndering individual migration to the escape-hatch output type, which is crit= ical to the systemic migration of Bitcoin away from relying on EC cryptogra= phy. >=20 > So your proposal does address one of my concerns with a P2MR + PQ opcode = strategy. However, i still believe P2TRv2 to be a superior strategy for the= reason outlined above. >=20 > Best, > Antoine >=20 > [^0]: Using 57.5*2 + 43*2 =3D 201 vbytes as the base size. P2MR adds an a= dditional 32 witness bytes 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 m= ore vbytes per input, which is 116.66% the size of the same transaction wit= h P2TRv2. > On Wednesday, June 3rd, 2026 at 7:26 PM, 'conduition' via Bitcoin Develop= ment Mailing List wrote: >=20 > > Hi list. I'm following up on an idea I sketched in=C2=A0this thread deb= ating P2MR vs P2TRv2.=C2=A0 > > The premise is this: What if we modified this line of BIP360: > >=20 > >=20 > > > The last stack element is called the control block c, and must have l= ength 1 + 32 * m, for a value of m that is an integer between 0 and 128, in= clusive. Fail if it does not have such a length. > >=20 > >=20 > > To this: > >=20 > >=20 > > > The last stack element is called the control block c, and must have l= ength 1 + 32 * m, for a value of m that is an integer between=C2=A01=C2=A0a= nd 128, inclusive. Fail if it does not have such a length. > >=20 > >=20 > > The key change is that the control block must now include at least one = merkle authentication path. This effectively bans depth-zero script trees i= n P2MR, and requires every P2MR address to always pay the cost of having at= least two spending conditions. > >=20 > > This seems like a reduction in P2MR's features and efficiency. Why woul= d we want to ban depth-zero script trees?=C2=A0Well these seem to be the so= urce of a perverse incentive, as pointed out by Matt Corallo and Antoine Po= insot in=C2=A0prior threads. Bitcoin script users are economically and prac= tically incentivized by P2MR to use depth-zero script trees because their w= itnesses are smaller than if the same script were used in a taproot script = spend. > >=20 > >=20 > > Furthermore, depending on the exact scripts and the developers' resourc= es, devs using P2MR for a multi-party scripting protocol may not be suffici= ently incentivized to add a cooperative spending path, even if their protoc= ol might allow it. Doing so would require a depth-1 tree, which increases t= he witness size of the non-cooperative script spend path by 32 bytes. For s= ome short scripts, e.g ` CLTV CHECKSIG`, the devs may actu= ally have incentive not to add a cooperative spending path, because the coo= perative path would actually be less-efficient than just using the non-coop= erative 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. > >=20 > > In=C2=A0Matt's words: > >=20 > >=20 > > > The value=C2=A0of taproot is that its design natively adds [a coopera= tive spending 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=C2=A0ecosystem... > >=20 > > > a goal of taproot is *privacy* while=C2=A0offering efficiency for the= common (all-sign) case. That is generally true across contracting protocol= s and makes things net-cheaper with a taproot-style system where you hit th= e common case=C2=A0often. This is another reason why P2MR is quite a loss > >=20 > >=20 > > By eliminating depth-zero script trees, we'd force all P2MR users to pa= y for the cost of having at least two spending conditions. We'd eliminate t= he incentive for script devs to use P2MR over P2TR because both are equally= efficient, and incentivize P2MR users to add a cooperative spending path u= sing BIP340, since those users are already paying for the cost of having a = depth-1 tree anyway. > >=20 > > This change to BIP360 wouldn't affect the recommended standard use-case= s for single-signer and multisig P2MR: hybrid addresses with one Schnorr le= af and one PQ leaf. If anything, this change would encourage the proper use= of PQ fallback scripts, because the incentive logic can be applied to some= one who tries to use P2MR with only a single EC Schnorr leaf: This user mus= t pay for the cost of a second leaf script anyway, so why not follow best-p= ractices and add a PQ leaf? > >=20 > > AFAICT this change only affects use cases which would otherwise degrade= the fungibility of the UTXO set according to BIP360 critics, and encourage= s 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. > >=20 > > I've already chatted about this off-list with some BIP360 proponents an= d they seem receptive, but I'm really curious about the opinions of those w= ho are leaning towards P2TRv2. Would this change to BIP360 address your con= cerns surrounding P2MR's privacy incentives? If not, why? > >=20 > > regards, > > conduition > >=20 > >=20 > >=20 > >=20 > > -- > > You received this message because you are subscribed to the Google Grou= ps "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/bitcoin= dev/Q8YTY1ArMzia7tRvcZ5v769WPxCMxAl_0rUy-byOBjBcTd4HXj7IB7Yt4gxLbKqk7EXFWy-= PuGB6QtI28qRjE5Vob-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/= doSPUSJvChwux9prI1puFj9OMI_ZeCeIEb1KKhnlp6G_wnpkvZmo3FZvvMRvaLAhzQFF2NS1Ad1= tHDWfnmf6ytLI7oMotciw64hUZkHoI68%3D%40proton.me. -----------------------6da062a6b2ca5554c711666b99d78dd4 Content-Type: multipart/related;boundary=---------------------df2ff9bc378633e1511ef43237b03c50 -----------------------df2ff9bc378633e1511ef43237b03c50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Antoine, thanks for the feedback. Glad to hear you're re= ceptive!

It's import= ant 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 an output ty= pe 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 an escape-hatch ou= tput 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 f= or everybody to migrate, but there is little incentive for each individual = to migrate if nobody else does.)

Therefore any additional barrie= r to encourage users to opt into an escape-hatch output type is working aga= inst CRQC risk mitigation.

All else being equal, whether we use P2MR or P2TRv2 I believe w= e will end up with roughly the same (small) fraction of the UTXO set migrat= ed by Q-day. I believe this because address format adoption is always slow = even with good incentives. Even after 7 years and plenty of incentives to m= igrate, P2TR still secures only a small fraction of the UTXO-set compared t= o P2(W)PKH, and a tiny fraction (0.75%) of the supply. See = this 2025 report from mempool.space and this 2025 report from Galaxy = Digital. Incentivizing adoption doesn't always lea= d to adoption, so why expect it to do so with P2TRv2? It doesn't offer any = incentive over P2TR beyond a shallow promise of maybe-some-day-quantum-s= ecurity.

Here's my timeline predict= ion, with the above precedent in mind. We deploy a PQ output type, some min= ority of UTXOs migrate to it. When the first confirmed ECDLP break is prove= n (e.g. if someone breaks a NUMS point) or suspected (someone stole Satoshi= 's coins), then we will deploy a rescue protocol which we hopefully prepare= d in advance to protect the majority procrastinator UTXOs. Maybe we disable= EC spending at the same time (a valid option for either P2MR or P2TRv2).&n= bsp;Then there will be a brief fork-war (hard or soft) revolving around the= question of how to handle Satoshi's coins. After that IDK what happens, bu= t I expect Bitcoin will survive if we prepare adequately today by deploying= a quantum-safe address format and PQ signature scheme, and develop rescue = protocols for later activation to move laggards over to PQ wallets.

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

<= span style=3D"font-family: Arial, sans-serif;">any additional barrier to en= courage users to opt into an escape-hatch output type is working against CR= QC 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 to BIP360 which w= ould 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 more info.

regards,
conduition
On Friday, June 5th, 2026 at 3:56 PM, Antoine Poinsot <darosior@= protonmail.com> wrote:
Hi conduition,

I think this would address the perverse incentive concern, but sti= ll fail in not disincentivizing mass migration.

It's important to consider that in= any scenario where Bitcoin as we know it survives a CRQC, the vast majorit= y of users would have had to migrate to an output type that includes an esc= ape hatch long before we could have been reasonably certain that a CRQC wou= ld materialize. Therefore we should not assume that the vast majority of us= ers strongly desire to migrate to an escape-hatch output type. (In fact, i = think it would actually be reasonable to assume none have a strong desire t= o 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 el= se does.)

Therefore any additional barrier to encourage users to opt into an escap= e-hatch output type is working against CRQC risk mitigation. And i think th= e additional costs of using P2MR compared to P2TRv2 is one of them. Most li= kely all "long-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-output transaction for a "single-key wallet", P2MR is ab= out 15% more expensive to use than P2TRv2 [^0].

I understand that P2MR does not in= troduce this additional cost just for kicks, but i think "long-range" prote= ction is a red-herring and not worth hindering individual migration to the = escape-hatch output type, which is critical to the systemic migration of Bi= tcoin away from relying on EC cryptography.

So your proposal does address one of m= y concerns with a P2MR + PQ opcode strategy. However, i still believe P2TRv= 2 to be a superior strategy for the reason outlined above.

Best,
Antoine

[^0]: Using 57.5*2 + 43*2 =3D 201 vbytes as the b= ase size. P2MR adds an additional 32 witness bytes in the control block for= the PQ spend path, and an additional 35 witness bytes for the EC leaf scri= pt reveal. That's 33.5 more vbytes 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> wr= ote:
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/doSPUS= JvChwux9prI1puFj9OMI_ZeCeIEb1KKhnlp6G_wnpkvZmo3FZvvMRvaLAhzQFF2NS1Ad1tHDWfn= mf6ytLI7oMotciw64hUZkHoI68%3D%40proton.me.
-----------------------df2ff9bc378633e1511ef43237b03c50-- -----------------------6da062a6b2ca5554c711666b99d78dd4-- -----------------------697354900f4283bac5c210961b82352c Content-Type: application/pgp-keys; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgp4ak1FWkRub0tSWUpLd1lCQkFI YVJ3OEJBUWRBcnBZYWFjZDgwcXdocmNaQW9VbW9NSHNWS21iZWlPZUEKcFhXbk1ybFdPZkxOSzJO dmJtUjFhWFJwYjI1QWNISnZkRzl1TG0xbElEeGpiMjVrZFdsMGFXOXVRSEJ5CmIzUnZiaTV0WlQ3 Q2pBUVFGZ29BUGdXQ1pEbm9LUVFMQ1FjSUNaQjRLV3p0aFBhenhRTVZDQW9FRmdBQwpBUUlaQVFL YkF3SWVBUlloQkVkSWthMENNdHJMZGcxM2EzZ3BiTzJFOXJQRkFBQTZhQUVBM1RmNHdqSVoKYnox K0diS0h4K09WQytNUXlVdi84RStoWUpjTE5QZnA0NEFBLzNiak5OTXN4WHdJTGZEM0xManNVVWFo CitBV2JyblVjVUFqQ2R1d3hUT01LempnRVpEbm9LUklLS3dZQkJBR1hWUUVGQVFFSFFDSXYxZW5J MU5MbAo3Zm55RzlVWk1wQ3ZsdG5vc0JrTmhQUVZxT3BXL3RKSkF3RUlCOEo0QkJnV0NBQXFCWUpr T2VncENaQjQKS1d6dGhQYXp4UUtiREJZaEJFZElrYTBDTXRyTGRnMTNhM2dwYk8yRTlyUEZBQUFR TFFEL2NCR2kwUDdwCkZTTkl2N1B6OVpkeUNVQjhzTy90dWZkV3NjQkNZK2ZMYTV3QkFNK0hTL3Jp S014RGt0TkhLakRGc2EvUgpEVDFxUGNBYXZCaXc2dDZ4Ti9jRgo9Y3d5eAotLS0tLUVORCBQR1Ag UFVCTElDIEtFWSBCTE9DSy0tLS0tCg== -----------------------697354900f4283bac5c210961b82352c-- --------0dbd1793f244bd8717f9d69008c9b2b0c305585340d1e9e16b49630cc30817a8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmojUv8JEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmdaOgpywKFAvRQ0EynsWZwOcHUXcFWSAR2gHDW6 RMIpYxYhBEdIka0CMtrLdg13a3gpbO2E9rPFAAD6LAEAue/0t+qDXIxDNuCN DiNbshrlltap/+73ZR9S1JZu3pMBAPEG6VtAuus4uPm466QOzjhDJ49bUR+M r2koDOGzFQ4A =Ft4g -----END PGP SIGNATURE----- --------0dbd1793f244bd8717f9d69008c9b2b0c305585340d1e9e16b49630cc30817a8--