From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 06 Jun 2026 12:35:53 -0700 Received: from mail-oa1-f60.google.com ([209.85.160.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 1wVwoB-0008LO-Q8 for bitcoindev@gnusha.org; Sat, 06 Jun 2026 12:35:53 -0700 Received: by mail-oa1-f60.google.com with SMTP id 586e51a60fabf-440ec63f571sf4802470fac.0 for ; Sat, 06 Jun 2026 12:35:51 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1780774545; cv=pass; d=google.com; s=arc-20240605; b=ENMJFnz71sngeKrVPGQMdFtTC5PSrZ7O42cAoTpLRNhQ/p+tpr1HCUaSzF55mOiY8i CQD8mnohR15SrJwZduk47flsrSu7WvBSnjdfM4Db0Pdst5PuYLAx7lcfJVwidrpq9KNq nTV401VRWjRm4e+YnI+bapSjFvLSNQNv4INVYJPrJYLu7DFT5ePGy+vtYB2eIuAmA+d3 Xx8NOCYDRaL5mgeF/XOKI+U6Gd2XFnF+xB0fYrm289XbJbh6VK6UL+0ZvqTJ27lTtq4r hh+Hj9mz9VinKySWyQJM54CyUY075M1ewRK9XW+ebixIrlpLZss7vXIK4ADc0M4m3LXM qRfg== 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=ODAhIvdIiLsD617CCBUfBEJGDi8+24CaxfnLCzPr0Oc=; fh=dSk5CO7TBXeeydYQgI/H1T5ol0gN8Uopv44HzEpZBbE=; b=lbjUHVBWuZ7S6wxaB0h/kvZtFgSDzwwqnx0QY3Uimc3U99s9Qnh4Ay9fLU4/dWv8mj um3hlMj4wgUhG7HPnMNU0LRWI/I2oL1k/TJasNdHLHJzFYFqI2gWESlokjeenOJ8lE8T ouYL147pyXXabgDkFz+F0vjJ7h6YyBG44p9z0ozDIt55eLHiFIiZq7ZQY56hk5ObX1ni nxzQMxxcHdh+8LwqswceptoNzww4quwy4sEO7rGRXuEm1UAlWrHRsvrn9PruHrjLeLp2 VyMYU5Hw7y6KN3X8ib3yWBZSKcS+G8CgL+zrfiUrT7uZeyxCCe4E10vP+9MPv1IguGWd 0N+Q==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=e2qbxyw7ynfazhzmgurdqpqg5e.protonmail header.b="H0gZGs/p"; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.97 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=1780774545; x=1781379345; 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=ODAhIvdIiLsD617CCBUfBEJGDi8+24CaxfnLCzPr0Oc=; b=r4hmZsn85AgX6Z+lnEFg6VGs2a9fc1NyPip6NeCOiHnJWDGjOn0P3CmeOZw+Mr7ec1 UecKV3erJ3DrQudKf6x0d2ok6NFe0BPr8tM+nfVPFfui+dwo0BhV8l8cLpZ2nltf1dFi NrMc0mFK5wGVYb31IEV7VL9Rag89DvxQIJXKiuYvSDLejKBl7v/VCv5oDCGDTFo9s0xP 6auU/9eN8ml3rLrFomRbe8b8QApMlma33+cDH2QLq5jPRdEvHIks3nH3qWiPzPqbJ30Y tAvu2UuNIh55x9TFEh+1yThTOv3Q7/bwJHnq+IHkx2O6EJJaZ9oebFojU6CHEpITSl/7 mblA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780774545; x=1781379345; 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=ODAhIvdIiLsD617CCBUfBEJGDi8+24CaxfnLCzPr0Oc=; b=JEvlZI9rlRvqt5mXxAifk+ByXSiFtZqpzkdZ6070ZPfRDqhgoCTxziFCU2cYGvE8qE 9ZCyaM5PMFQ3hzuBhRg26nmJb/V8RM4VRft91J8DHa08QWdRDCiWYutloEDAl1gjDY/n KiFx1skxkPdFw6jaZC+NJxnjNr/kuk4n4ebme7CSOm0QdZ7RnlUO8Mpdb1xBN8D+edWX EGWxtaFxQbcHA3UQaRJSO14+/zQGnCoauS0d+Id63d1zFW7DfVdmwB+zWEuH6cCymrFv WRL2NQoZ2yrPygTVAF2O9Bf5+cnVU8Zy0MwextWyUFzxBgNt0CwhB1m6gM1r/cRMLcR1 QhKQ== X-Forwarded-Encrypted: i=2; AFNElJ9VCC5jhpfH8cR6Zrh8xRAvw3QKR+RCnc9O0uZw8IuqJGCo5Jc+m668rje0JTxbxDMjJpL6c+ZVWVF2@gnusha.org X-Gm-Message-State: AOJu0YxO+EM0OUFiFtCsRqjUx/kdkAvNTMA6v6owA+Uvk45iLjP4X8h5 y1L0IpV9KKGRP2LN6F99hpBbqSBh2vQU3vv7sw69ia7YS3sJ7B+nbSmd X-Received: by 2002:a05:6870:c192:b0:430:16b5:909 with SMTP id 586e51a60fabf-44145e56c89mr2997487fac.15.1780774545126; Sat, 06 Jun 2026 12:35:45 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUcTuWtkVz31gzexTmWGj4pvc/DfjOlmJxz/z0Pi/9WFRQ==" Received: by 2002:a05:6870:3a1a:b0:43d:33ef:23cb with SMTP id 586e51a60fabf-440d865ada1ls1354072fac.2.-pod-prod-00-us-canary; Sat, 06 Jun 2026 12:35:40 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ8mBHHbnydVjJC/Odun0mtLDJ9WaAZSLxb3eJJpb1aNDFZBC90G/TF+eEHRywijFXgpg6abPSWJ3+8K@googlegroups.com X-Received: by 2002:a05:6808:2393:b0:485:8678:d248 with SMTP id 5614622812f47-48692c87fe9mr3745741b6e.1.1780774540138; Sat, 06 Jun 2026 12:35:40 -0700 (PDT) Received: by 2002:a05:600c:c059:10b0:485:53e3:ec5e with SMTP id 5b1f17b1804b1-490c2546a9cms5e9; Sat, 6 Jun 2026 12:33:28 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ8mrOBYAKcH+avl1hMgcdQFOSTk/6humo7h7EIBX2YQw3rZQYCyVTNogulUDT9bLD8+Q6B0SL9E/4dx@googlegroups.com X-Received: by 2002:a05:600c:1d14:b0:490:b02d:1529 with SMTP id 5b1f17b1804b1-490c25b3562mr162030115e9.6.1780774407284; Sat, 06 Jun 2026 12:33:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1780774407; cv=none; d=google.com; s=arc-20240605; b=K0gL97usitxPl+Eg8zgx+Srb8ZmVN5FlqjBx8Pkvk/WyGll/KN9rrpPudYQPIMSXpv FUJhIx+z6qZ5G3QBZlCD6/ZXwFIL6d8EAgyfaPlFDCFRRwG5DKBRIMv4Mavzru/eHXmU jbATlkn2W+Q6Sl72iOteoR3mWlOP/gKPImkfOjw5lxZgazpcqb+ARtwjG0eyJCaexZsH TVO3G1mY56C3cYZ7N7jiPU9lfiTQ68yQXIIb5MRVUQEyz9HEIeRamwQEuKoqEcRaHr3L IImYgyx8Qg7W8+AvazpVRsfKjNLjlEx+ONlpWfXPGqN6AYelAnDbW3l82kSmEWEgIhQb 0ySg== 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=yQRegZQa/k1M+EXvSJtWnwsfi4jl92B/VzoX3kFEl/k=; fh=U9ccRNGf+BW2NF32FKpsuS15uCE2U1idoXsNEmQleBg=; b=d8390MP3rIphDGlOUgXJ8Hv2YxFzj4C4RABs8iIJ9bShQfWjFl6v/mFOwP4/qJcWD9 GMF8lcNE50qT7tMQ5wAQHZOHhkGVnBk9zjD1Ums9Q14DhuBIf/tg+VkvevWLjwFWKsZf gmwiHuLZiHQtlvezGJattc5Tq5PqqbJYg8Q59JmX///cKvMCJme5jqbPLsgGSbXn6u3V hhc89fIlK9CrT4pkOUl+hvD5FEiADc7wp6qGMXZP6hn9TjvsygNrytj/jw881Q4PM5Zb FNxU0GvhTqSwu6WXCePLLjuwXVLesRbf6b+IFDqnu1qzS69zNyalEUySpCcGW7shCihU NKNQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=e2qbxyw7ynfazhzmgurdqpqg5e.protonmail header.b="H0gZGs/p"; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.97 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-10697.protonmail.ch (mail-10697.protonmail.ch. [79.135.106.97]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-490c2d30e9csi1030005e9.1.2026.06.06.12.33.27 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 06 Jun 2026 12:33:27 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 79.135.106.97 as permitted sender) client-ip=79.135.106.97; Date: Sat, 06 Jun 2026 19:33:15 +0000 To: Pieter Wuille From: "'conduition' via Bitcoin Development Mailing List" Cc: Antoine Poinsot , "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: 669ecf4f9fdee16e4f6d4cc448ed47163d7525da MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------3ee68d59a666841fade8787bbe9f8733225b4a7b7307dc349db562c2580dc3a2"; 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=e2qbxyw7ynfazhzmgurdqpqg5e.protonmail header.b="H0gZGs/p"; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.97 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) --------3ee68d59a666841fade8787bbe9f8733225b4a7b7307dc349db562c2580dc3a2 Content-Type: multipart/mixed;boundary=---------------------5df2be0a77f51c11bcbdf97ca67f34cb -----------------------5df2be0a77f51c11bcbdf97ca67f34cb Content-Type: multipart/alternative;boundary=---------------------cfc9bc77ddb74fdb8895da7fa34ea1cd -----------------------cfc9bc77ddb74fdb8895da7fa34ea1cd Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hey Pieter, nice to hear from you too on this.=C2=A0 Do you have any take on the OP idea about P2MR depth restrictions? > as far as compelling reasons go, I think the quantum resistance debate is= quite different from P2TR adoption. As Q-fear grows, I suspect there will = be increasingly loud and hard-to-ignore voices (and possibly regulation...)= to adopt post quantum cryptography technology stacks. I hope so too! It's totally possible that a significant majority of UTXOs m= igrate in time - say if you're right and there is a very public concerted p= ush towards PQ, or if Q-day turns out to be 50+ years from now. But it's im= possible to predict this. For now I hope for the best, but I also want to p= lan for the worst. If PQ fear is indeed such a strong motivating factor as you hypothesize, wo= uldn't this be an argument against P2TRv2? P2TRv2 isn't quantum-resistant b= y default but P2MR is. Personally, if I thought a CRQC is imminent, I would= rather sell my coins or stow them in a P2WSH address than migrate to an ad= dress format which requires a follow-up fork to be secure.=C2=A0 To borrow a phrase, P2TRv2 bears a systemic risk=C2=A0(solving the fork tim= ing problem), whereas P2MR has only=C2=A0local risk (address reuse,=C2=A0wh= ich btw would also be solved if we could solve fork-timing). Antoine drew t= his comparison on his post too but we apparently disagree on which is prefe= rable. Users and devs can control local risk with very simple software tweaks (to = avoid address reuse) but they can't do anything about systemic risks. This = is why I prefer P2MR. If the fork-timing problem can be solved conclusively= then maybe P2TRv2 would be viable, but as you've alluded to, we have yet t= o hear any passable solution that doesn't require a cooperative CRQC. > No offense, but this sounds like a fairly depressing scenario to me. If a= n ECDLP break happens before even a large majority of the "active" economy = adopts Q-safe outputs, I don't think there is much of an interesting future= for Bitcoin. Leaving many users' coins vulnerable to theft will undermine = short-term trust in the currency, possibly fatally so. The alternative, bur= ning significant amounts of users' coins will be seen as confiscation that = undermines the long-term stability value proposition bitcoin has, as it wou= ld be indistinguishable from a PQC altcoin that imports some fairly arbitra= ry subset of Bitcoin's UTXO set (see also=C2=A0https://antoinep.com/posts/q= uantum_risk_mitigation/, where Antoine makes that point in more detail). Agreed, it would suck, but would likely be viable. I lack data, but I suspect that by Q-day most coins will have some knowledg= e-asymmetry with a CRQC (hash preimages, BIP32 parent keys, hidden P2TR scr= ipt paths, etc) and so can be rescued with simple commit/reveal protocols -= no heavy ZK machinery or hard-forks needed. With that in mind, then it doesn't really matter how many recoverable coins= migrate before Q-day, does it? If you can assume P2TRv2's PQ-security prom= ise will be deployed on-time, then you can also assume any BIP32 wallet in-= use today can be rescued. What we really must care about is migrating the u= nrecoverable fraction of coins (e.g. JBOK wallets with exposed pubkeys). Th= ese should already be rare and will only become rarer as more time passes. So in order to argue your point that P2TRv2 makes confiscation/theft less l= ikely, you'd need to show that P2TRv2 will result in a meaningfully higher = number of unrecoverable coins migrating. And I don't see why that would be = the case. Holders of ancient JBOK coins with exposed keys are probably eith= er dead, or have lost their keys. If a holder does still have the keys, the= n why would they move to P2TRv2 but not P2MR? On a more positive note, if we can someday say "Look, quantum computers app= eared and screwed some people over, but most people can recover their coins= as long as they fulfill any one of these common criteria," then that seems= like Bitcoin's unique value and confiscation resistance is surprisingly in= tact to me. Certainly better than certain other altcoin migrations I've see= n in the past, but I guess this is a subjective question, and everyone will= have their own opinion. > It's possible to allow a Merkle tree whose leaves are either EC keys or s= cripts, and then allow spending from the key-leaves by revealing the path a= nd a signature, but recover the expected public key from the signature. Tha= t needs a variation of BIP340 that doesn't commit to the public keys (which= may break some of the proofs of higher-level schemes, but as long as there= is no ANYPREVOUT like functionality, the message implicitly commits to the= output so that may be fine). But even with that, efficiency is 32 bytes wo= rse than P2TR, because in a Q-safe setting with at least one additional PQC= branch, you have at least 32 bytes of Merkle path. Is this what you have i= n mind? Sorry to string you along but I'm gonna hold off here as I don't want to ta= ke credit for the idea by jumping the gun and explaining it myself. I'll le= ave it open for the actual author to chime in on this thread if/when he's r= eady :) > A reasonable intersection of both opinions could be further witness disco= unt of EC Schnorr of P2MR (Segwit v2). > Further 2x witness discount (total 8x witness discount) makes P2MR EC-spe= nd transaction cost almost at par with P2TRv2 key-spend path. I wouldn't rule out a discount in a future upgrade but for now i'm hesitant= to bundle PQ addresses/signatures with anything that might disrupt the exi= sting fee market, especially given the frustratingly controversial topic of= inscriptions/spam. I can already picture the Knotsies decrying a witness-d= iscounted PQ soft fork as "spam-support hidden behind quantum FUD". Never m= ind that we're already going to have to bump the stack element size limit..= . regards, conduition On Saturday, June 6th, 2026 at 12:30 AM, Pieter Wuille wrote: > Hi Conduition, >=20 > Some comments inline below. >=20 > On Friday, June 5th, 2026 at 6:59 PM, 'conduition' via Bitcoin Developmen= t Mailing List wrote: >=20 > > Hi Antoine, thanks for the feedback. Glad to hear you're receptive! > >=20 > >=20 > > > 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.) > >=20 > > >=20 > > >=20 > > > Therefore any additional barrier to encourage users to opt into an es= cape-hatch output type is working against CRQC risk mitigation. > >=20 > >=20 > > All else being equal, whether we use P2MR or P2TRv2 I believe we will e= nd up 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 wit= h 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)P= KH, and a tiny fraction (0.75%) of the supply.=C2=A0See=C2=A0this 2025 repo= rt from mempool.space=C2=A0and this 2025 report from Galaxy Digital. Incent= ivizing adoption doesn't always lead to adoption, so why expect it to do so= with P2TRv2? It doesn't offer any incentive over P2TR beyond a shallow pro= mise of maybe-some-day-quantum-security. >=20 >=20 > I don't think that's necessarily the right conclusion. P2TR adoption is l= ow, partially because wallets and especially commercial service providers g= enerally don't ever upgrade their technology stacks unless there is a compe= lling reason; the ecosystem primarily updates through companies going out o= f business and being replaced by new ones, which are more likely to be buil= t using modern technology. We obviously cannot ask for faster movement thro= ugh business failure here, but as far as compelling reasons go, I think the= quantum resistance debate is quite different from P2TR adoption. As Q-fear= grows, I suspect there will be increasingly loud and hard-to-ignore voices= (and possibly regulation...) to adopt post quantum cryptography technology= stacks. At that point, wallets may start to offer users an "Upgrade to qua= ntum-resistant addresses?" migration button. In the case of P2MR that will = need to come with a "Warning: transactions will cost 15% more going forward= " notice. In the case of P2TRv2, depending on what what used before it may = have 0 impact on costs, or even be a discount going forward. If on-chain fe= es remain as low as they are now, this may not matter, but otherwise, I thi= nk the number may very well discourage a substantial amount of users who ar= en't convinced about CRQC threats. And I think those users do matter, unfor= tunately. >=20 >=20 > > Here's my timeline prediction, with the above precedent in mind. We dep= loy a PQ output type, some minority of UTXOs migrate to it. When the first = confirmed ECDLP break is proven (e.g. if someone breaks a NUMS point) or su= spected (someone stole Satoshi's coins), then we will deploy a rescue proto= col which we hopefully prepared in advance to protect the majority procrast= inator 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. A= fter that IDK what happens, but I expect Bitcoin will survive if we prepare= adequately today by deploying a quantum-safe address format and PQ signatu= re scheme, and develop rescue protocols for later activation to move laggar= ds over to PQ wallets. >=20 >=20 > No offense, but this sounds like a fairly depressing scenario to me. If a= n ECDLP break happens before even a large majority of the "active" economy = adopts Q-safe outputs, I don't think there is much of an interesting future= for Bitcoin. Leaving many users' coins vulnerable to theft will undermine = short-term trust in the currency, possibly fatally so. The alternative, bur= ning significant amounts of users' coins will be seen as confiscation that = undermines the long-term stability value proposition bitcoin has, as it wou= ld be indistinguishable from a PQC altcoin that imports some fairly arbitra= ry subset of Bitcoin's UTXO set (see also=C2=A0https://antoinep.com/posts/q= uantum_risk_mitigation/, where Antoine makes that point in more detail). >=20 > I cannot confidently state that your scenario is unlikely of course, but = I think there is little we can do today that affects the outcome in this ca= se. People can think about emergency recovery scenarios to scavenge what's = left to save (BIP32 ZKPs and all that), and the result may well survive, bu= t I don't think it'll be very interesting, and not something we as protocol= designers should optimize for at this stage. >=20 > The interesting scenarios to me are ones where either a CRQC doesn't happ= en, or where we get a large majority of users to adopt Q-safe outputs befor= e that happens. Maximizing the probability that that will happen should be = our priority. >=20 >=20 > > Whether we pick P2MR or P2TRv2 today, neither choice will affect the ea= rly stages of this plot-line very much, so we might as well optimize for th= e long-term future, and P2MR wins out there. >=20 >=20 > The ideal long-term future is one where we get feature-rich cryptographic= schemes that can replace most of the properties Bitcoin relies on today (h= omomorphic derivation, efficient multisigs, ...) with low costs (through di= scounts, smaller signatures/keys, efficient verification, ...). At that poi= nt, they can be introduced in PQC-only outputs even (say, P2MR without any = EC opcodes ever), everyone can adopt them over time, and then when a CRQC a= ppears or not won't really matter. That technology does not exist today, I = think, so the best we can aim for today is something where most users can m= igrate to with minimal downsides before Q-day, even if it comes with some d= ownsides afterwards, which will inevitably be chaotic but maybe not an exis= tential threat. I don't think it matters much that P2TR(v2) is slightly les= s efficient than P2MR in this hopefully-avoidable chaos; we'll have much bi= gger fish to fry. >=20 > I believe P2MR is effectively optimizing for the time after/if a CRQC app= ears (possibly only temporarily so if another migration to a more fully-fea= tures PQC scheme is needed anyway then) while P2TRv2 is optimizing for the = time before a CRQC happens and minimizing barriers for adopting Q-safe coin= s. All of this is under the assumption that P2MR comes with a reasonable ex= pectation of a narrow P2MR-only EC opcode disabling softfork when CRQCs hap= pen (like P2TRv2); without it, I believe it is much worse, as P2MR would be= entirely inadvisable to adopt by anyone whose workflow relies on sharing p= ublic keys with others (hardware wallets with descriptor-based watchonly so= ftware, wallets with indexing servers, multisig, Lightning, escrows, fee bu= mping, ...). >=20 > So, I prefer P2TRv2 here, though under the assumption that the narrow EC = opcode disabling softfork can be relied upon. I am not confident that that = is possible, though I have more thoughts on the matter. That's for another = post, though. >=20 >=20 > > > any additional barrier to encourage users to opt into an escape-hatch= output type is working against CRQC risk mitigation. And i think the addit= ional costs of using P2MR compared to P2TRv2 is one of them. > >=20 > >=20 > > I have good news for you: there is an optimization to BIP360 which woul= d 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, bu= t expect another mailing list post soon with more info. >=20 >=20 > It's possible to allow a Merkle tree whose leaves are either EC keys or s= cripts, and then allow spending from the key-leaves by revealing the path a= nd a signature, but recover the expected public key from the signature. Tha= t needs a variation of BIP340 that doesn't commit to the public keys (which= may break some of the proofs of higher-level schemes, but as long as there= is no ANYPREVOUT like functionality, the message implicitly commits to the= output so that may be fine). But even with that, efficiency is 32 bytes wo= rse than P2TR, because in a Q-safe setting with at least one additional PQC= branch, you have at least 32 bytes of Merkle path. Is this what you have i= n mind? > --=C2=A0 > Pieter >=20 --=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/= jVpYczjMUwILN76cjc9LSoXttkuOrkClgAX6gwtlQ4-lVEcGFKD8tEp72zhTCzCqmOdyrkyuoyG= F2DA-p5WebDgmgXyAGpBnH6mYRGvl1-I%3D%40proton.me. -----------------------cfc9bc77ddb74fdb8895da7fa34ea1cd Content-Type: multipart/related;boundary=---------------------0313b7e309592959816645f4c18dec8c -----------------------0313b7e309592959816645f4c18dec8c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Pieter, nice to hear f= rom you too on this. 

Do you have any take on the OP idea about P2MR depth restrict= ions?
<= span>as far as compelling reasons go, I think the quantum resistance debate= is quite different from P2TR adoption. As Q-fear grows, I suspect there wi= ll be increasingly loud and hard-to-ignore voices (and possibly regulation.= ..) to adopt post quantum cryptography technology stacks.
=

I hope so too! It's totally possible that a significant majori= ty of UTXOs migrate in time - say if you're right and there is a very publi= c concerted push towards PQ, or if Q-day turns out to be 50+ years from now= . But it's impossible to predict this. For now I hope for the= best, but I also want to plan for the worst.

If PQ fear is indeed such a strong motiva= ting factor as you hypothesize, wouldn't this be an argument against P2TRv2= ? P2TRv2 isn't quantum-resistant by default but P2MR is. Personally, if I t= hought a CRQC is imminent, I would rather sell my coins or stow them in a P= 2WSH address than migrate to an address format which requires a follow-up f= ork to be secure. 
To borrow a phr= ase, P2TRv2 bears a systemic risk (solving the fork timing prob= lem), whereas P2MR has only local risk (address reuse,&n= bsp;which btw would also be solved if we could solve fork-timing). Antoine = drew this comparison on his post too but we apparently disagree on which is= preferable.

Users and devs can control= local risk with very simple software tweaks (to avoid address reuse) but t= hey can't do anything about systemic risks. This is why I prefer P2MR. If t= he fork-timing problem can be solved conclusively then maybe P2TRv2 would b= e viable, but as you've alluded to, we have yet to hear any passable soluti= on that doesn't require a cooperative CRQC.

No offense, but this sounds like a fairly depressing= scenario to me. If an ECDLP break happens before even a large majority of = the "active" economy adopts Q-safe outputs, I don't think there is much of = an interesting future for Bitcoin. Leaving many users' coins vulnerable to = theft will undermine short-term trust in the currency, possibly fatally so.= The alternative, burning significant amounts of users' coins will be seen = as confiscation that undermines the long-term stability value proposition b= itcoin has, as it would be indistinguishable from a PQC altcoin that import= s some fairly arbitrary subset of Bitcoin's UTXO set (see also https://antoinep.com/posts/quantum_ris= k_mitigation/, where Antoine makes that point in more detail).

Agreed, it would= suck, but would likely be viable.

I lack data, but I suspect that by Q-day mos= t coins will have some knowledge-asymmetry with a CRQC (hash preimag= es, BIP32 parent keys, hidden P2TR script paths, etc) and so can be rescued= with simple commit/reveal protocols - no heavy ZK machinery or hard-forks = needed.

With that in mind, then it does= n't really matter how many recoverable coins migrate before Q-day, d= oes it? If you can assume P2TRv2's PQ-security promise will be deployed on-= time, then you can also assume any BIP32 wallet in-use today can be rescued= . What we really must care about is migrating the unrecoverable frac= tion of coins (e.g. JBOK wallets with exposed pubkeys). These should alread= y be rare and will only become rarer as more time passes.

So in order to argue your point that P2TRv2 makes conf= iscation/theft less likely, you'd need to show that P2TRv2 will result in a= meaningfully higher number of unrecoverable coins migrating. And I = don't see why that would be the case. Holders of ancient JBOK coins with ex= posed keys are probably either dead, or have lost their keys. If a holder d= oes still have the keys, then why would they move to P2TRv2 but not P2MR?

On a more positive note, if we can somed= ay say "Look, quantum computers appeared and screwed some people over, b= ut most people can recover their coins as long as they fulfill any one of t= hese common criteria," then that seems like Bitcoin's unique value and = confiscation resistance is surprisingly intact to me. Certainly better than= certain other altcoin migrations I've seen in the past, but I guess this i= s a subjective question, and everyone will have their own opinion.

It's possible to allow a Merk= le tree whose leaves are either EC keys or scripts, and then allow spending= from the key-leaves by revealing the path and a signature, but recover the= expected public key from the signature. That needs a variation of BIP340 t= hat doesn't commit to the public keys (which may break some of the proofs o= f higher-level schemes, but as long as there is no ANYPREVOUT like function= ality, the message implicitly commits to the output so that may be fine). B= ut even with that, efficiency is 32 bytes worse than P2TR, because in a Q-s= afe setting with at least one additional PQC branch, you have at least 32 b= ytes of Merkle path. Is this what you have in mind?
=
Sorry= to string you along but I'm gonna hold off here as I don't want to take cr= edit for the idea by jumping the gun and explaining it myself. I'll leave i= t open for the actual author to chime in on this thread if/when he's ready = :)

A reasonable intersection of both opinions could be further w= itness discount of EC Schnorr of P2MR (Segwit v2).
Further = 2x witness discount (total 8x witness discount) makes P2MR EC-spend transac= tion cost almost at par with P2TRv2 key-spend path.
=
<= span>

regards,
conduition

On Saturday, June 6th, 2026 at 12:30 AM, Pieter Wuille <bitcoin-= dev@wuille.net> wrote:
Hi Conduition,

Some comments inline below.
<= br>
On Friday, June 5th, 2026 at 6:59 = PM, 'conduition' via Bitcoin Development Mailing List <bitcoind= ev@googlegroups.com> 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 it sur= vives a CRQC, the vast majority of users would have had to migrate to an ou= tput type that includes an escape hatch long before we could have been reas= onably certain that a CRQC would materialize. Therefore we should not assum= e that the vast majority of users strongly desire to migrate to an escape-h= atch output type. (In fact, i think it would actually be reasonable to assu= me none have a strong desire to do so. This is because everyone has an ince= ntive for everybody to migrate, but there is little incentive for each indi= vidual to migrate if nobody else does.)

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 wi= ll end up with roughly the same (small) fraction of the UTXO set migrated b= y 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 migra= te, 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. See this 2025 report from me= mpool.space and
I don't think that's necessarily the right conclusion. P2= TR adoption is low, partially because wallets and especially commercial ser= vice providers generally don't ever upgrade their technology stacks unless = there is a compelling reason; the ecosystem primarily updates through compa= nies going out of business and being replaced by new ones, which are more l= ikely to be built using modern technology. We obviously cannot ask for fast= er movement through business failure here, but as far as compelling reasons= go, I think the quantum resistance debate is quite different from P2TR ado= ption. As Q-fear grows, I suspect there will be increasingly loud and hard-= to-ignore voices (and possibly regulation...) to adopt post quantum cryptog= raphy technology stacks. At that point, wallets may start to offer users an= "Upgrade to quantum-resistant addresses?" migration button. In the case of= P2MR that will need to come with a "Warning: transactions will cost 15% mo= re going forward" notice. In the case of P2TRv2, depending on what what use= d before it may have 0 impact on costs, or even be a discount going forward= . If on-chain fees remain as low as they are now, this may not matter, but = otherwise, I think the number may very well discourage a substantial amount= of users who aren't convinced about CRQC threats. And I think those users = do matter, unfortunately.

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 confirmed ECDLP break is proven (e.g. i= f someone breaks a NUMS point) or suspected (someone stole Satoshi's coins)= , then we will deploy a rescue protocol which we hopefully prepared in adva= nce to protect the majority procrastinator UTXOs. Maybe we disable EC spend= ing at the same time (a valid option for either P2MR or P2TRv2). 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, but I expec= t Bitcoin will survive if we prepare adequately today by deploying a quantu= m-safe address format and PQ signature scheme, and develop rescue protocols= for later activation to move laggards over to PQ wallets.


I cannot confidently state that your scenario is unlikely of cour= se, but I think there is little we can do today that affects the outcome in= this case. People can think about emergency recovery scenarios to scavenge= what's left to save (BIP32 ZKPs and all that), and the result may well sur= vive, but I don't think it'll be very interesting, and not something we as = protocol designers should optimize for at this stage.

The interesting scenarios to me are ones where either a CRQC= doesn't happen, or where we get a large majority of users to adopt Q-safe = outputs before that happens. Maximizing the probability that that will happ= en should be our priority.

Whether we pick P2MR or P2TRv2 tod= ay, 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.
The ideal long-term= future is one where we get feature-rich cryptographic schemes that can rep= lace most of the properties Bitcoin relies on today (homomorphic derivation= , efficient multisigs, ...) with low costs (through discounts, smaller sign= atures/keys, efficient verification, ...). At that point, they can be intro= duced in PQC-only outputs even (say, P2MR without any EC opcodes ever), eve= ryone can adopt them over time, and then when a CRQC appears or not won't r= eally matter. That technology does not exist today, I think, so the best we= can aim for today is something where most users can migrate to with minima= l downsides before Q-day, even if it comes with some downsides afterwards, = which will inevitably be chaotic but maybe not an existential threat. I don= 't think it matters much that P2TR(v2) is slightly less efficient than P2MR= in this hopefully-avoidable chaos; we'll have much bigger fish to fry.

I believe P2MR is effectively optimizing f= or the time after/if a CRQC appears (possibly only temporarily so if anothe= r migration to a more fully-features PQC scheme is needed anyway then) whil= e P2TRv2 is optimizing for the time before a CRQC happens and minimizing ba= rriers for adopting Q-safe coins. All of this is under the assumption that = P2MR comes with a reasonable expectation of a narrow P2MR-only EC opcode di= sabling softfork when CRQCs happen (like P2TRv2); without it, I believe it = is much worse, as P2MR would be entirely inadvisable to adopt by anyone who= se workflow relies on sharing public keys with others (hardware wallets wit= h descriptor-based watchonly software, wallets with indexing servers, multi= sig, Lightning, escrows, fee bumping, ...).

So, I prefer P2TRv2 here, though under the assumption that the narrow = EC opcode disabling softfork can be relied upon. I am not confident that th= at is possible, though I have more thoughts on the matter. That's for anoth= er post, though.

<= /div>
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.

I have good n= ews for you: there is an optimization to BIP360 which would make single-sig= ner 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.

It's possible to allo= w a Merkle tree whose leaves are either EC keys or scripts, and then allow = spending from the key-leaves by revealing the path and a signature, but rec= over the expected public key from the signature. That needs a variation of = BIP340 that doesn't commit to the public keys (which may break some of the = proofs of higher-level schemes, but as long as there is no ANYPREVOUT like = functionality, the message implicitly commits to the output so that may be = fine). But even with that, efficiency is 32 bytes worse than P2TR, because = in a Q-safe setting with at least one additional PQC branch, you have at le= ast 32 bytes of Merkle path. Is this what you have in mind?

=
-- 
Pieter


--
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/jVpYcz= jMUwILN76cjc9LSoXttkuOrkClgAX6gwtlQ4-lVEcGFKD8tEp72zhTCzCqmOdyrkyuoyGF2DA-p= 5WebDgmgXyAGpBnH6mYRGvl1-I%3D%40proton.me.
-----------------------0313b7e309592959816645f4c18dec8c-- -----------------------cfc9bc77ddb74fdb8895da7fa34ea1cd-- -----------------------5df2be0a77f51c11bcbdf97ca67f34cb 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== -----------------------5df2be0a77f51c11bcbdf97ca67f34cb-- --------3ee68d59a666841fade8787bbe9f8733225b4a7b7307dc349db562c2580dc3a2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmokdeoJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmd4klO/dEXI6VMSy99HP9D8t3tsmDlY3xd3NwLT mKluThYhBEdIka0CMtrLdg13a3gpbO2E9rPFAACBaAEA32o3PCiXI4aGs3uu q0QIax08NFarr56wn+uXkpQfFP8A/i+c3R0LG+Tn1K8RpZVTSaYKHvuwaIDo uxUsHrFR8vkM =uqyV -----END PGP SIGNATURE----- --------3ee68d59a666841fade8787bbe9f8733225b4a7b7307dc349db562c2580dc3a2--