From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 06 Jun 2026 11:00:20 -0700 Received: from mail-oa1-f63.google.com ([209.85.160.63]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wVvJi-00072d-Ty for bitcoindev@gnusha.org; Sat, 06 Jun 2026 11:00:20 -0700 Received: by mail-oa1-f63.google.com with SMTP id 586e51a60fabf-43d052ba649sf4221790fac.1 for ; Sat, 06 Jun 2026 11:00:17 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1780768808; cv=pass; d=google.com; s=arc-20240605; b=ESubW5Nh/VPAcXr5p6htWAt3I7qgBGqc/kHvMYyR/PfId2aweXmKB5Srr8dsOm/i8U XYiET2zWKJvwKbIWXKFdmSTKj2e9bdmIjEjpmOqg4qiJ+dK0U45oQiCToSJdfyO764Xd 7nWEaH1DmMPjuFXq0dgoCiSxE7y1uqhbJiofHnTaCZ1AzrffWbiYLNfeqNBDqVb1aFwd Ylrvinb70TZ7Tczrr+BTXzFtHCm8ijxmc744x82tsqhVRd7j9zVLUd4xXTP+TimHKTag XvBzkREiTLf1I1mavUNZDvjEwLOIwi0ucmODtnpaFhzQzXt4hXbkZfd2ngbdJv4vVsyU 3PNQ== 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:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:sender :dkim-signature; bh=gx5OcxHbxXNgEHos8NAipjzPuTB3MBWMowBYAq/H4zk=; fh=V4fS35wmHdo1EUVj80M+RDvDIw4rlFfq1fpWrrRTx00=; b=ZcaCd02jj5gmeVvOewqw9ztUek8aEBYSIfmXcVSRlsL8Sx/IMy8qnppm3yEFjYny2B 5FFSh7JLEXErOg3GIa1gGoJJpYzX3K18VsD9XiQctgSfND1MoRexsOk8WUsS7xiyu8fC Tr4dRV9YprA2DX6lc09X1fuIxCjn9EVfci8Wj4HThzwrQYbKB6hXBCrxu8jciN/GtUnk GIHvks0pZFp9dwyFT+O1yEflmjlnY0yuVk8S0EA54cqfyF8jGPMpLleLJ2P3KX9nz3KZ u3oek9SgK7ATwb99pjK7IYi7pzQU1srwmHQzViEY3Gtx9zJVEYIZSnpKfNF/fd47yqp+ z27w==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@wuille.net header.s=protonmail header.b="hpb2/nyz"; spf=pass (google.com: domain of bitcoin-dev@wuille.net designates 79.135.106.105 as permitted sender) smtp.mailfrom=bitcoin-dev@wuille.net; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=wuille.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1780768808; x=1781373608; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:mime-version:feedback-id:references:in-reply-to :message-id:subject:cc:from:to:date:sender:from:to:cc:subject:date :message-id:reply-to; bh=gx5OcxHbxXNgEHos8NAipjzPuTB3MBWMowBYAq/H4zk=; b=tWoDu5n5e87lNs2YDV3tEHdchOt74mj1RzUtyvoIi0RVik+tdgDvkXp707lM3DG0C/ 5bQLmf2hpDwB061lGaGX8czDGujITS9owXXSck12lQNrcXRW9x1/6yU09GpLQAE6QfEj uEOrwTTLRVWjiPMMkii88Ob1orcf+5MuXo5mG/w9BKHaFu/PLSBx3yzB8BWADs6DbnYU 5hvaFgjVrbEDu6JSgIhAOh1EeIHdkOv72gMGXhIxV2iTTbDTfN44RhNiIy6MahC1bXqU qcEnUPN7In65aXdDeffOhAbmCNxE+sl5tY/JEyrDrzjIbvQGuZ43tXb6isntZiv8ys81 wfiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780768808; x=1781373608; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence: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 :sender:from:to:cc:subject:date:message-id:reply-to; bh=gx5OcxHbxXNgEHos8NAipjzPuTB3MBWMowBYAq/H4zk=; b=bhQ14K3OjPPjzqeI13owvnS5/BaWvo6Hkijh0+tcDoCcSMEfbCxQAbJQKX9yOpgU9E NDvCVCqKZeQfgcpPpIvdLEAAFc7SHfmQ86C3wANYZBISxeOVqQsjLy4FtvoSmC+2ZltF /x0CQiBa3OOLtM+NdCjOdXa5JDYLKllwZYZJHGkKFCQ9o7LIvw5aYiMw81T0gHaViSvC 1fuVPutsSyH1UJAJfG5Y8ahnN/VkCMbBMHt0/QIeDAecDeuG//AIlMJbnBLhWaMe68jU hZXx/d6uhnAHuUZUOTmtLb5nxKGXaT1nYWsLHuE95IIRMBCq8L7MOuT46K6nj19/VEqc 7tUw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AFNElJ8YFqVzQMXpKPN+AubdOBXmp6lSIj9ZQMA2PeQcAvNo11hQvGrhcVuCnAIoNWxK8T8igAtWmQzt4bY+@gnusha.org X-Gm-Message-State: AOJu0Yzhero03giwc5TgOreU1Ee/2nOo/hkDt4ZbLK+Vcqt/VdUCM77/ JP1ATvKH13bKp7JoA+8ihYSubW6d+CXjagVQAfaJLTXjDX1OvpMtqBcW X-Received: by 2002:a05:6870:489:b0:43b:7f1e:6d20 with SMTP id 586e51a60fabf-4413d242f73mr4767837fac.7.1780768807937; Sat, 06 Jun 2026 11:00:07 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUdSJETNHyqWpBW2S5Z4ckSCkIDNnjWM1I2QLpYB/ZVolQ==" Received: by 2002:a05:687c:3392:b0:440:dc16:6d79 with SMTP id 586e51a60fabf-4410960e081ls1470597fac.0.-pod-prod-07-us; Sat, 06 Jun 2026 11:00:01 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ/ENVKfbLd0b8Cir+sAXwWr98k/h6L0G0iySICAYjY/ZRwrZFkAAnB2+5qGVU0b71tCYOPbvX1A0QS5@googlegroups.com X-Received: by 2002:a05:6808:1508:b0:47c:be93:9212 with SMTP id 5614622812f47-4868dc7aa8dmr5311375b6e.18.1780768800911; Sat, 06 Jun 2026 11:00:00 -0700 (PDT) Received: by 2002:a05:600c:c059:10b0:485:53e3:ec5e with SMTP id 5b1f17b1804b1-490c2546a9cms5e9; Fri, 5 Jun 2026 21:30:04 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ//YhyW7DsyDAWYOmjSJYXGqzdEbEfERFbiirB87g7UeQkdw9Ad0crm2qACp8VSYVb9j3/gvxMJdqJM@googlegroups.com X-Received: by 2002:a5d:4a90:0:b0:45e:eec6:500c with SMTP id ffacd0b85a97d-4603065b523mr7063883f8f.39.1780720203423; Fri, 05 Jun 2026 21:30:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1780720203; cv=none; d=google.com; s=arc-20240605; b=eru4dtAFSob1oyXvMQ8QPEobS0poSJ3O7m37Ph9svyGR3ekNYeaVOMSsxTAqrveP7P JU8MJcIABzvgazfRLAFAbufXOuhWKNSHZd1Mv/KN8S20rpqI4sA+saJ/+06aWzsACkL/ E7uazKcPlV5HUnMumpB7luF6apu4nlD7GLBzXPrH53dv5NCLcfkDcS4avxzp4NCQcYqv oeYCs7lWyyLWhbdjSOuVUEwugghN0i315uyi1Bpp82jJxGEPkWsqW+P1KBjVVCERnAtk ZYlmI4l72fjw320dwDyJJaD/bJeAH2mtZaBYT4uCidYVOFDSA3dNkcW0QVfPzUt21G1x oesQ== 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=yvIwHO71jfNpzoDCHEYjo+anB7GibktoThnfKP+8V1U=; fh=D2zN9mv8jVn5Hb696WOH8AcKnxQ3Rlerek2KxSdkxlE=; b=SwRtIi3wIgbtntFmSfUkuuvjxjFJGSI525AYT4ZgGvJFZoVbhJ7u/MECSLMhJxmOhs JaojL3q9bihzLAqrWPwARv1CDrUFf6LND3xHL0j3bg5ObC1W+pJiPbtqjjtVIy4W621q Hd7pbIAFe+e/gpUJmJOtUDQ1G0HftjoE20uByoIjCUej+HnExFm4cOsZqoMQnIxhtVRb Vo6eMQJK7ARsfnpk2mjEpdPaO7ijXrVJ6i5RLL6MBOg7NKqbsVsfDevqcj5AeFRdND5D mUvrAI6km12GP+hNesNojcWT636eTwNxprZqGF+1UsRhnh7266jqJzVstRsmDZIE1rM5 /lPg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@wuille.net header.s=protonmail header.b="hpb2/nyz"; spf=pass (google.com: domain of bitcoin-dev@wuille.net designates 79.135.106.105 as permitted sender) smtp.mailfrom=bitcoin-dev@wuille.net; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=wuille.net Received: from mail-106105.protonmail.ch (mail-106105.protonmail.ch. [79.135.106.105]) by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-4601f322bcesi240047f8f.3.2026.06.05.21.30.03 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Jun 2026 21:30:03 -0700 (PDT) Received-SPF: pass (google.com: domain of bitcoin-dev@wuille.net designates 79.135.106.105 as permitted sender) client-ip=79.135.106.105; Date: Sat, 06 Jun 2026 04:29:57 +0000 To: conduition From: Pieter Wuille Cc: Antoine Poinsot , "bitcoindev@googlegroups.com" Subject: Re: [bitcoindev] Aligning privacy incentives in P2MR Message-ID: In-Reply-To: References: Feedback-ID: 19463299:user:proton X-Pm-Message-ID: f36f1f1e62f558e4a8c6b148507367d08eb9505c MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_kiSQG4oblkh0qSYW4maxbpGsnTOwcB9LhkhXDocOQ" X-Original-Sender: bitcoin-dev@wuille.net X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@wuille.net header.s=protonmail header.b="hpb2/nyz"; spf=pass (google.com: domain of bitcoin-dev@wuille.net designates 79.135.106.105 as permitted sender) smtp.mailfrom=bitcoin-dev@wuille.net; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=wuille.net Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.7 (/) --b1=_kiSQG4oblkh0qSYW4maxbpGsnTOwcB9LhkhXDocOQ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Conduition, Some comments inline below. On Friday, June 5th, 2026 at 6:59 PM, 'conduition' via Bitcoin Development = Mailing List 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 survives a CRQC, the vast majority of users would have had to migrate t= o an output type that includes an escape hatch long before we could have be= en reasonably certain that a CRQC would materialize. Therefore we should no= t assume that the vast majority of users strongly desire to migrate to an e= scape-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 ea= ch individual to migrate if nobody else does.) > >> Therefore any additional barrier to encourage users to opt into an escap= e-hatch output type is working against CRQC risk mitigation. > > All else being equal, whether we use P2MR or P2TRv2 I believe we will end= up with roughly the same (small) fraction of the UTXO set migrated by Q-da= y. I believe this because address format adoption is always slow even with = good incentives. Even after 7 years and plenty of incentives to migrate, P2= TR 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 mem= pool.space](https://research.mempool.space/utxo-set-report/) and [this 2025= report from Galaxy Digital](https://www.galaxy.com/insights/research/bitco= in-onchain-fees-utxo). Incentivizing adoption doesn't always lead to adopti= on, so why expect it to do so with P2TRv2? It doesn't offer any incentive o= ver P2TR beyond a shallow promise of maybe-some-day-quantum-security. I don't think that's necessarily the right conclusion. P2TR adoption is low= , partially because wallets and especially commercial service providers gen= erally don't ever upgrade their technology stacks unless there is a compell= ing reason; the ecosystem primarily updates through companies going out of = business and being replaced by new ones, which are more likely to be built = using modern technology. We obviously cannot ask for faster movement throug= h business failure here, but as far as compelling reasons go, I think the q= uantum resistance debate is quite different from P2TR adoption. As Q-fear g= rows, I suspect there will be increasingly loud and hard-to-ignore voices (= and possibly regulation...) to adopt post quantum cryptography technology s= tacks. At that point, wallets may start to offer users an "Upgrade to quant= um-resistant addresses?" migration button. In the case of P2MR that will ne= ed 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 ha= ve 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, unfortu= nately. > Here's my timeline prediction, with the above precedent in mind. We deplo= y a PQ output type, some minority of UTXOs migrate to it. When the first co= nfirmed ECDLP break is proven (e.g. if someone breaks a NUMS point) or susp= ected (someone stole Satoshi's coins), then we will deploy a rescue protoco= l which we hopefully prepared in advance to protect the majority procrastin= ator UTXOs. Maybe we disable EC spending at the same time (a valid option f= or either P2MR or P2TRv2). Then there will be a brief fork-war (hard or sof= t) revolving around the question of how to handle Satoshi's coins. After th= at IDK what happens, but I expect Bitcoin will survive if we prepare adequa= tely today by deploying a quantum-safe address format and PQ signature sche= me, and develop rescue protocols for later activation to move laggards over= to PQ wallets. 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 ad= opts Q-safe outputs, I don't think there is much of an interesting future f= or Bitcoin. Leaving many users' coins vulnerable to theft will undermine sh= ort-term trust in the currency, possibly fatally so. The alternative, burni= ng significant amounts of users' coins will be seen as confiscation that un= dermines the long-term stability value proposition bitcoin has, as it would= be indistinguishable from a PQC altcoin that imports some fairly arbitrary= subset of Bitcoin's UTXO set (see also https://antoinep.com/posts/quantum_= risk_mitigation/, where Antoine makes that point in more detail). 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 case= . People can think about emergency recovery scenarios to scavenge what's le= ft to save (BIP32 ZKPs and all that), and the result may well survive, but = I don't think it'll be very interesting, and not something we as protocol d= esigners 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 happen should be ou= r priority. > Whether we pick P2MR or P2TRv2 today, neither choice will affect the earl= y 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 s= chemes that can replace most of the properties Bitcoin relies on today (hom= omorphic derivation, efficient multisigs, ...) with low costs (through disc= ounts, smaller signatures/keys, efficient verification, ...). At that point= , 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 app= ears or not won't really matter. That technology does not exist today, I th= ink, so the best we can aim for today is something where most users can mig= rate to with minimal downsides before Q-day, even if it comes with some dow= nsides afterwards, which will inevitably be chaotic but maybe not an existe= ntial 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 bigg= er fish to fry. I believe P2MR is effectively optimizing for the time after/if a CRQC appea= rs (possibly only temporarily so if another migration to a more fully-featu= res PQC scheme is needed anyway then) while P2TRv2 is optimizing for the ti= me before a CRQC happens and minimizing barriers for adopting Q-safe coins.= All of this is under the assumption that P2MR comes with a reasonable expe= ctation of a narrow P2MR-only EC opcode disabling softfork when CRQCs happe= n (like P2TRv2); without it, I believe it is much worse, as P2MR would be e= ntirely inadvisable to adopt by anyone whose workflow relies on sharing pub= lic keys with others (hardware wallets with descriptor-based watchonly soft= ware, wallets with indexing servers, multisig, Lightning, escrows, fee bump= ing, ...). So, I prefer P2TRv2 here, though under the assumption that the narrow EC op= code 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 po= st, though. >> > >> any additional barrier to encourage users to opt into an escape-hatch ou= tput type is working against CRQC risk mitigation. And i think the addition= al 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 = 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. It's possible to allow a Merkle tree whose leaves are either EC keys or scr= ipts, 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 that doesn't commit to the public keys (which m= ay break some of the proofs of higher-level schemes, but as long as there i= s no ANYPREVOUT like functionality, the message implicitly commits to the o= utput so that may be fine). But even with that, efficiency is 32 bytes wors= e than P2TR, because in a Q-safe setting with at least one additional PQC b= ranch, you have at least 32 bytes of Merkle path. Is this what you have in = mind? -- Pieter --=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/= sHzHpzprjPTKHmfSy0Oes6FGD1nd_M36z2SiY3LDHmh3dI2YQWSfy-Xu4cZDe9nbEgihL0o9yZN= 7PEx6_rsEyPTcX-nJOTtiM2DX8SVOES4%3D%40wuille.net. --b1=_kiSQG4oblkh0qSYW4maxbpGsnTOwcB9LhkhXDocOQ Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Conduiti= on,

Som= e comments inline below.

On Friday, June 5th, 2026 at 6:59 PM, 'conduit= ion' via Bitcoin Development Mailing List <bitcoindev@googlegroups.com&g= t; 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 sta= te that your scenario is unlikely of course, 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 a= nd all that), and the result may well survive, but I don't think it'll be v= ery interesting, and not something we as protocol designers should optimize= for at this stage.
The interesting sce= narios 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. Maxim= izing the probability that that will happen should be our priority.

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

The ideal long-term future is one where we get feat= ure-rich cryptographic schemes that can replace most of the properties Bitc= oin relies on today (homomorphic derivation, efficient multisigs, ...) with= low costs (through discounts, smaller signatures/keys, efficient verificat= ion, ...). At that point, 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 appears or not won't really matter. That technology do= es not exist today, I think, so the best we can aim for today is something = where most users can migrate to with minimal downsides before Q-day, even i= f 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 P2= TR(v2) is slightly less efficient than P2MR in this hopefully-avoidable cha= os; we'll have much bigger fish to fry.

I believe P2MR is effectively optimizing for the time after/if a CRQC appe= ars (possibly only temporarily so if another migration to a more fully-feat= ures PQC scheme is needed anyway then) while P2TRv2 is optimizing for the t= ime before a CRQC happens and minimizing barriers for adopting Q-safe coins= . All of this is under the assumption that P2MR comes with a reasonable exp= ectation of a narrow P2MR-only EC opcode disabling softfork when CRQCs happ= en (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 pu= blic keys with others (hardware wallets with descriptor-based watchonly sof= tware, wallets with indexing servers, multisig, Lightning, escrows, fee bum= ping, ...).

=
So, I prefer P2TRv2 here, t= hough 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 mo= re thoughts on the matter. That's for another post, though.

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

I have good news for you: there is an optimiz= ation to BIP360 which would make single-signer Schnorr spending significant= ly (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 allow a Merkle tree whose leaves are e= ither EC keys or scripts, and then allow spending from the key-leaves by re= vealing the path and a signature, but recover 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, bu= t as long as there is no ANYPREVOUT like functionality, the message implici= tly commits to the output so that may be fine). But even with that, efficie= ncy is 32 bytes worse 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 th= is 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/sHzHp= zprjPTKHmfSy0Oes6FGD1nd_M36z2SiY3LDHmh3dI2YQWSfy-Xu4cZDe9nbEgihL0o9yZN7PEx6= _rsEyPTcX-nJOTtiM2DX8SVOES4%3D%40wuille.net.
--b1=_kiSQG4oblkh0qSYW4maxbpGsnTOwcB9LhkhXDocOQ--