From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 11 Jun 2026 02:35:16 -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 1wXboh-0003Xk-9r for bitcoindev@gnusha.org; Thu, 11 Jun 2026 02:35:16 -0700 Received: by mail-oa1-f59.google.com with SMTP id 586e51a60fabf-43d08878f48sf12638180fac.0 for ; Thu, 11 Jun 2026 02:35:15 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1781170509; cv=pass; d=google.com; s=arc-20240605; b=Nk0qtgV+qY11Awzzq+jP+9jK1LyEQLH3egXxnGvG+L2MsBwqEJQP6GFFIkj+AkW9hK LXcPdEra5ZNpf798Ir96HXgSCyIiooBqk8VaDjpSXquoWId4oyyT6FUJPAXQKO8EcLLc su0FOvYWtBTRBTIr9nFfwsy7VvEhQTbR4LXL5+qR1uAV4Ib43oOrWbLFI8OV+8RJs7jV 0Yni2RYUSlBoJ3CTq3N6ELmjzXJM684KhEDi72KVKibwSXrxaEs4QdUD6n/zXKRIDUtJ l8+Ych3J8DMUyTwsN3yXONaYysJh96ockm5aMh5KbJ33BiyEnvVvtzn8v/LZWbDlNJ/m PwmQ== 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=0nnh98WHyJanTIPsUF6z65MeDmiIvwiO/3jojZpyTas=; fh=7d4M/jYovQ8yWW7aEcEySqNk9N0ZyorP1MKHJWIwpk8=; b=br4PtNwVyHardgK6VRIl/L31Tpz9SNE3InKxRsGBuAFZFHi5PySbjDxfg393oZ119X eDhI09fN4c65eG8uhaxllLehOwz0qtWypGkzb6bFtHsQstWEOj91WjWppZ+0gY5OZlUQ wV9PgB+8NMYJcugLxubazr9buBAmJMkhErNa3Fhovond2gn9o6Rk5ERjdnRf0DEegCA+ t2Pfz7FMWPOmgdSvedjtxGtoQ4vilaxA1ixuEmUFM6aRXZ3JITJaxO/cPW+8yQzoikbM 5vJIcoypTefZ7nR2YZQialPpSKTNoJmxrdlMb6iHI6ifPMUVBb9q1UWUGXxMzK711jwc meLg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@wuille.net header.s=protonmail header.b=TqBQVe1e; spf=pass (google.com: domain of bitcoin-dev@wuille.net designates 185.70.43.20 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=1781170509; x=1781775309; 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=0nnh98WHyJanTIPsUF6z65MeDmiIvwiO/3jojZpyTas=; b=QFUjPu7LKr1blCuR3nPbYAc2+2dpcfJBV/G9tgu0o7fFglQyk+3jnFHK47Wr7vUsDT Z1Vx9Gq6CxotZk4MNQhz/1lrKlfFZtUcwF2FpLnM7h7dX4aAMsdZu/6mBVtkXfQVyHQA tf8P4WK/RUhiZ0T+uh5Zmwra/5RTekXnxwVzMXGzlYobsHi+CF++p1wga/T3wkzOMWbQ DXBnMzY6MFXvpFvFRzdHU5beZiQP6tp2M4KMiCrra2ql4Mc0/W0KWpBtZC9GW4hApQJe L/UBOi0Na9riKXfQivn6eSe7Q4Usld60+zcQFsVIJWHcQrmcaoA197LV2UM2Cd5wRDb2 FuuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781170509; x=1781775309; 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=0nnh98WHyJanTIPsUF6z65MeDmiIvwiO/3jojZpyTas=; b=rjzDEujAxRkL2cseS6lFxuBiz8R/WHZHCIqrA3ofUQi9eqtOO9tW862tXG8yb2mQD2 aQzhrX3K6db4MOs8kIXfpBexXPCsUF5JRBbJAcOpPLKM54GBezu6LekXuzRI4dFhqZvJ W8zImlQmMx2nBuYckH+1stnWMsg0vEKw4K2efuekvY8w9709ohnEjAW/9fEHRsRz7V5/ /RicsoyYOBd00WH186L+6KB8/j1PyulNjVCUHv7AHuoBCU9pMtBcmjoRM2lwlWnttKRZ 5DAANZ5347jeh1b/J3Cm/+IIdC1/38NIY6NSP36fZtrpLl4Rt2VVVmD0PMfnVYOqakYr 5ufg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AFNElJ+31AzsUQYTar0co22s7imKZURarlHFobFPvUU8r52LEgNZZ4fTpC6K0mA+HEZ7Aw4o3J2L3GV9P0AN@gnusha.org X-Gm-Message-State: AOJu0YxIlSN4HM1SG6/wgfDZ78h2A1wus1GXYOKLD6OOAQGbe9Mb2xGG LkS7feVs6emjcspXni5c9lxwsk1hgbun22eiKcXX3ERJqUCWe5UDPZt9 X-Received: by 2002:a05:6870:c095:b0:434:2c00:fd84 with SMTP id 586e51a60fabf-442416d19b3mr1104175fac.10.1781170509226; Thu, 11 Jun 2026 02:35:09 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUeVy0Az7hHfpOrkG86fIbauIOo6jEDAexBQvycrJ/nI4A==" Received: by 2002:a05:6870:2101:b0:435:a654:4449 with SMTP id 586e51a60fabf-44109904368ls4874019fac.1.-pod-prod-05-us; Thu, 11 Jun 2026 02:35:05 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ+uimi8VVCuD/M39TrRie/qdlTOFNIF9TVlsE2foHQpHw76p97cTedd/ijkv5OqSEHZQv4VBVffsaUT@googlegroups.com X-Received: by 2002:a05:6808:1806:b0:480:42da:e125 with SMTP id 5614622812f47-4871a3b1e48mr1344009b6e.36.1781170505827; Thu, 11 Jun 2026 02:35:05 -0700 (PDT) Received: by 2002:ab3:5087:0:b0:2e5:dca6:8eb2 with SMTP id a1c4a302cd1d6-3045428eb04msc7a; Tue, 9 Jun 2026 20:00:32 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ8AE/wL/HK9SeyaqLo0k4yXm6zN2y9U/0jzAJuCWRqsT3AT1x3hpINvSq8FPynbQG5iGyohpZ6bWFRa@googlegroups.com X-Received: by 2002:a05:651c:150c:b0:394:942:9bb6 with SMTP id 38308e7fff4ca-397f76b9b36mr16552011fa.6.1781060430887; Tue, 09 Jun 2026 20:00:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1781060430; cv=none; d=google.com; s=arc-20240605; b=NlEcJgl4rVSal32ymPj7rs2IvPfSQsV4eXNxlW3axm+Jh0+MVRxljvgAno56TxEGEM vJ7xMfdYjzV8pDZKBG4HbvrVukkpxDGQgcwIXjeGdbC3332E3IX/4qNEqrAD1fisUtgY F4MpQesL2Pv/m3AotSLeKtnkN9pMGCD+CogxR7J3b2dBeu/8jEwNmso8TmpQjWxGwJgk Z13BtaDZHtThnKDNRRSQKjN41P2pJeyq5y0WdlslTVNTaNXMuAois5jdxAL52xZ3JJWp F65ymvXfBulkezskIIccaUxkWy+sGh29fBCYoR8686EQriOdSy4B3f3lXE3jxZNAcxGA qVdQ== 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=YN3HAz/ZHy4Bd3vFgMLFxuhzmfVBSg9GssefTfkAuKc=; fh=D2zN9mv8jVn5Hb696WOH8AcKnxQ3Rlerek2KxSdkxlE=; b=W3JIXTkRmzJ2cn0sl4kwAisUJsrxdyoaKx2QadTsVQTkCs72ChUzEqVoHmxQMTTMNS qE+wYYtT3Hwa1PsUfhImoy6C/yvKW2LS1Ie2yAjlWYv94RRuCz57WNjO86K2YTx4DFwd cAvqKAN1KbMausaxTzsJ1nVG5V91Vu4Xr3iG0NwodtfZoHcTcoBsNfBicEWum9gB36+6 kgMYwloIG6+PrURTDNMv0FDFGUQuvUJCwRvCcZ0O8oavsAhFBp64n1EepbcfS9vQIGK1 AAYvubrwZji/jedNlQPc7M05PkXl104lhdRMIedeXQX2sV+oEY3tl/ESrlkjcwMVzmQC S+XA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@wuille.net header.s=protonmail header.b=TqBQVe1e; spf=pass (google.com: domain of bitcoin-dev@wuille.net designates 185.70.43.20 as permitted sender) smtp.mailfrom=bitcoin-dev@wuille.net; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=wuille.net Received: from mail-4320.protonmail.ch (mail-4320.protonmail.ch. [185.70.43.20]) by gmr-mx.google.com with ESMTPS id 38308e7fff4ca-396ac2128ccsi5970901fa.6.2026.06.09.20.00.30 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Jun 2026 20:00:30 -0700 (PDT) Received-SPF: pass (google.com: domain of bitcoin-dev@wuille.net designates 185.70.43.20 as permitted sender) client-ip=185.70.43.20; Date: Wed, 10 Jun 2026 03:00:27 +0000 To: conduition From: Pieter Wuille Cc: Antoine Poinsot , "bitcoindev@googlegroups.com" Subject: Re: [bitcoindev] Aligning privacy incentives in P2MR Message-ID: <_z6_JUmphCkUYvI6gemSFMD9Sb_rDL03IQbtZQCNlk6pmioGEQBir_gMyZCfticFa8Ttfc0xoFHdxR07_MNuAfBu8do_h5IDf2apVk1w1BM=@wuille.net> In-Reply-To: References: Feedback-ID: 19463299:user:proton X-Pm-Message-ID: a74ca6db708327adfedcf3993f638d53f6fc9a2f MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_TfpXMTX68LcGm8KgUnUBOfBllkcsREoJm0okvDFUc" 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=TqBQVe1e; spf=pass (google.com: domain of bitcoin-dev@wuille.net designates 185.70.43.20 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=_TfpXMTX68LcGm8KgUnUBOfBllkcsREoJm0okvDFUc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi conduition, See more comments inline below. On Saturday, June 6th, 2026 at 3:33 PM, conduition w= rote: > Hey Pieter, nice to hear from you too on this. > > Do you have any take on the OP idea about P2MR depth restrictions? I think it improves one aspect of the incentive differences (relative costs= within the output type for common vs. uncommon). The key recovery idea imp= roves another (relative costs w.r.t. P2TR in the common case). Even with bo= th, the result is still worse than P2TR today in both aspects (key-based sp= end is still more expensive compared to P2TR, and the incentive for key-bas= ed over script-based spend is weaker within P2MR). I want to take a step back however and separate the discussion into two som= ewhat orthogonal dimensions along which P2MR and P2TRv2 differ, because dis= cussing the details sometimes conflates them: - The exact commitment structure (Merkle root, variations with branch lengt= h / key recovery, Taproot structure, ...). - The expectation of when an EC-disabling consensus change happens: - "Never", or as part of a wide (not-output-specific) EC disabling/freeze (= P2MR) - "Later", through a later softfork that specifically disables EC narrowly = in that output type (P2TRv2) - "Now", Immediately in that output type ("P2QR", i.e., P2MR with all EC op= codes disabled from the start). Tweaking the commitment structure modifies the incentives of one over the o= ther under some conditions, but I think the question of when/how the EC-dis= abling happens is the more fundamental one, and it is largely independent o= f the commitment structure. I'll go into more detail below, but my reasonin= g is primarily that the "Never" and/or "Immediately" options are just insuf= ficient with current technology for any worthwhile migration attempt (indep= endent of which commitment structure is used), and thus that we simply need= the "Later" option. Once you accept that, there is a secondary line of rea= soning about which specific structure(s) are , and that is where taproot-ba= sed constructions come out ahead by having better incentives in the short- = to medium term (the numbers above mean essentially less/zero economical fri= ction). I also want to point out there that Merkle-Never and Merkle-Later are two v= ery fundamentally different things, and we can't just decide at a later poi= nt in time whether a narrow fork should still be applied. If the expectatio= n is no EC-disabling in it, then disabling is confiscatory. There is one technical difference where the specific commitment structure m= atters: P2MR ("Merkle-Never") can be used in a Q-safe way and a hypothetica= l "Taproot-Never" cannot (which includes P2TRv2, if you don't believe in be= ing able to rely on the future narrow disabling), which seems to be the pri= mary reason people like it. However, I think this is extremely restrictive,= and simply not an option for most users, because it means: - Not using wallet indexing services that transmit public keys/xpubs. - Not using hardware wallets with watchonly software wallets that rely on x= pubs/descriptors. - Not using multisig (or MuSig/threshold schemes/...). Even a PKH-based mul= tisig (as you suggested elsewhere) is icky due to parties needing to share = signatures with each with each other, of coins that aren't necessarily goin= g to be spent. - Not using Lightning. - Not using [silent payments](https://github.com/bitcoin/bips/blob/master/b= ip-0352.mediawiki). - Not using escrow services (like Blockstream's or BitGo's 2-of-3 wallet se= rvices). - Not spending fork coins / airdrops. - Never reusing addresses. Of course, with evolving technology and other developments, some of these r= estrictions may weaken. Alternatives for some of these may be developed, bu= t I don't think think fundamentally everything can be addressed. By their n= ature, public keys are designed to be public, and I don't believe we can re= alistically migrate the whole ecosystem (even in the long term) off that pr= emise. The real solution is feature-rich efficient PQC signature schemes of= course, but those do not exist today. If we want to start a migration in t= he near-term, with today's technology, it needs to be compatible with today= 's ecosystem. > If PQ fear is indeed such a strong motivating 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 thought a CRQC is imminent, I wou= ld rather sell my coins or stow them in a P2WSH address than migrate to an = address format which requires a follow-up fork to be secure. > > To borrow a phrase, P2TRv2 bears a systemic risk (solving the fork timing= problem), whereas P2MR has only local risk (address reuse, which btw would= also be solved if we could solve fork-timing). Antoine drew this compariso= n on his post too but we apparently disagree on which is preferable. This indeed touches on a fundamental difference in viewpoint. I believe the primary risk in both approaches ("Never" and "Later") is syst= emic! Bitcoin either as a whole migrates to PQC resistance, or not and ever= yone loses. If too many(*) vulnerable coins/users remain on Q-day, I believ= e the remaining options are all damaging for everyone, because a wide EC fr= eeze may be necessary to remain relevant (who would use a currency where ma= ny coins are vulnerable to theft?), but doing so likely undermines Bitcoin'= s long-term value proposition (how does it differ from an native-PQC altcoi= n bootstrapped with some arbitrary subset of Bitcoin's UTXO set?). Individu= al users adopting a quantum-resistant workflow without an expectation that = most other users will do the same is not a migration strategy, but a hedge = against Bitcoin's ability to meaningfully migrate in time. Yes, if availabl= e there will certainly be users taking it, but I'm not convinced it is bene= ficial for the success probability of currency-wide migration if a "Later" = option is available too, and possibly worse. The "Later" option does not have all the restrictions listed above, and I b= elieve has a chance of getting adopted in the medium term by everyone if av= ailable with sufficiently low friction. That of course brings us to how the= expectation of a future EC softfork can be relied upon. And it is somethin= g of a self-fulfilling prophecy I think. If literally all PQC defense of Bi= tcoin were to be done through one new output type, then it seems almost a g= iven that the EC disabling will happen in time: even if "Bitcoin" doesn't, = someone will create a fork that does so in time, and if it's that essential= , that fork will win. A concern may exist about potential disagreement with= in the community about when the disable-fork should occur, but I think it's= still a far better prospect than... essentially making Q-day a guaranteed = disaster apart from a few people that get to save their coins, if it happen= s before the future feature-rich efficient PQC signature schemes can be ado= pted. And if you accept that at least a "Later" option is needed, I think adding = more PQC options actually weakens it! If some people have their coins in "N= ever" or "Now" outputs in a PQC-safe manner (subject to the restriction / c= osts those bring), then that reduces the incentive to get the "Later" narro= w EC freeze to occur, and indirectly reduces the value of that output type. (*) =3D I don't know what numbers are the threshold here, or how users vs. = coins compares. Still, reducing the number of coins/users for which the "th= eft vs freeze" applies always seems like a win. > Users and devs can control local risk with very simple software tweaks (t= o avoid address reuse) but they can't do anything about systemic risks. I think you're vastly underestimating what is simple for most uses. Not sha= ring public keys or signatures with untrusted parties is a wildly different= world than we have today. > This is why I prefer P2MR. If the fork-timing problem can be solved concl= usively then maybe P2TRv2 would be viable, but as you've alluded to, we hav= e yet to hear any passable solution that doesn't require a cooperative CRQC= . I think it has a much higher chance of getting ~everyone on it in time, eve= n if there is no certainty. > I lack data, but I suspect that by Q-day most coins will have some knowle= dge-asymmetry with a CRQC (hash preimages, BIP32 parent keys, hidden P2TR s= cript paths, etc) and so can be rescued with simple commit/reveal protocols= - no heavy ZK machinery or hard-forks needed. I don't understand this, can you elaborate? Having a knowledge-asymmetry se= ems like something that matters for ZK machinery. > With that in mind, then it doesn't really matter how many recoverable coi= ns migrate before Q-day, does it? If you can assume P2TRv2's PQ-security pr= omise will be deployed on-time, then you can also assume any BIP32 wallet i= n-use today can be rescued. What we really must care about is migrating the= unrecoverable fraction of coins (e.g. JBOK wallets with exposed pubkeys). = These should already be rare and will only become rarer as more time passes= . I think anything relying on BIP32 recovery is disaster-recovery territory, = not interesting migration, because it'll inevitably be an arbitrary subset = that survives. It's something people can think about of course for use in c= ase of a Q-day before migration to PQC-safe outputs at scale happens. As I'= ve argued, that's probably an uninteresting outcome for everyone. People wi= ll want to do what they to save what remains, but I don't think it should r= eally matter in this discussion today. Also, It sounds like you're really saying that the systemic migration to PQ= C is something that will happen through a commit/reveal, not through what w= e're discussing now. So what is the point of having something like P2MR or = P2TRv2 in the near term? > On a more positive note, if we can someday say "Look, quantum computers a= ppeared and screwed some people over, but most people can recover their coi= ns as long as they fulfill any one of these common criteria," then that see= ms like Bitcoin's unique value and confiscation resistance is surprisingly = intact to me. Certainly better than certain other altcoin migrations I've s= een in the past, but I guess this is a subjective question, and everyone wi= ll have their own opinion. Yeah, I have a pretty different view here. -- 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/= _z6_JUmphCkUYvI6gemSFMD9Sb_rDL03IQbtZQCNlk6pmioGEQBir_gMyZCfticFa8Ttfc0xoFH= dxR07_MNuAfBu8do_h5IDf2apVk1w1BM%3D%40wuille.net. --b1=_TfpXMTX68LcGm8KgUnUBOfBllkcsREoJm0okvDFUc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi conduition,
<= br>
See more comments inline below.

On Saturday, June 6th, 2026 at 3:33 PM, conduition <conduition@proto= n.me> wrote:
Hey Pieter, ni= ce to hear from you too on this. 

Do you have any take on the OP idea about P2MR de= pth restrictions?

I= think it improves one aspect of the incentive differences (relative costs = within the output type for common vs. uncommon). The key recovery idea impr= oves another (relative costs w.r.t. P2TR in the common case). Even with bot= h, the result is still worse than P2TR today in both aspects (key-based spe= nd is still more expensive compared to P2TR, and the incentive for key-base= d over script-based spend is weaker within P2MR).

I want to take a step back however and separate the discussion i= nto two somewhat orthogonal dimensions along which P2MR and P2TRv2 differ, = because discussing the details sometimes conflates them:
  • The = exact commitment structure (Merkle root, variations with branch length / ke= y recovery, Taproot structure, ...).
  • The expectation of when an EC-disabling consensus chan= ge happens:
    • "Never", or as part of a = wide (not-output-specific) EC disabling/freeze (P2MR)
      • "Later", through a later softfork that specifically= disables EC narrowly in that output type (P2TRv2)
    • "Now", Immediately in that output type ("P2QR", i.e., = P2MR with all EC opcodes disabled from the start).
    <= /ul>

    Tweaking the = commitment structure modifies the incentives of one over the other under so= me conditions, but I think the question of when/how the EC-disabling happen= s is the more fundamental one, and it is largely independent of the commitm= ent structure. I'll go into more detail below, but my reasoning is primaril= y that the "Never" and/or "Immediately" options are just insufficient with = current technology for any worthwhile migration attempt (independent of whi= ch commitment structure is used), and thus that we simply need the "Later" = option. Once you accept that, there is a secondary line of reasoning about = which specific structure(s) are , and that is where taproot-based construct= ions come out ahead by having better incentives in the short- to medium ter= m (the numbers above mean essentially less/zero economical friction).

    I a= lso want to point out there that Merkle-Never and Merkle-Later are two very= fundamentally different things, and we can't just decide at a later point = in time whether a narrow fork should still be applied. If the expectation i= s no EC-disabling in it, then disabling is confiscatory.

    There is one tec= hnical difference where the specific commitment structure matters: P2MR ("M= erkle-Never") can be used in a Q-safe way and a hypothetical "Taproot-Never= " cannot (which includes P2TRv2, if you don't believe in being able to rely= on the future narrow disabling), which seems to be the primary reason peop= le like it. However, I think this is extremely restrictive, and simply not = an option for most users, because it means:
    • Not using wallet ind= exing services that transmit public keys/xpubs.
    • Not using hardware = wallets with watchonly software wallets that rely on xpubs/descriptors.
    • Not using multisig (or MuSig/threshold schemes/...). Even a PKH-based = multisig (as you suggested elsewhere) is icky due to parties needing to sha= re signatures with each with each other, of coins that aren't necessarily g= oing to be spent.
    • Not using Lightning.
    • Not using silent payments.
    • N= ot using escrow services (like Blockstream's or BitGo's 2-of-3 wallet servi= ces).
    • Not spending fork coins / airdrops.
    • Never reusing add= resses.

    Of course, with evolving technolog= y and other developments, some of these restrictions may weaken.= Alternatives for some of these may be developed, but I don't think think f= undamentally everything can be addressed. By their nature, public keys are = designed to be public, and I don't believe we can realistically migrate the= whole ecosystem (even in the long term) off that premise. The real solutio= n is feature-rich efficient PQC signature schemes of course, but those do n= ot exist today. If we want to start a migration in the near-term, with toda= y's technology, it needs to be compatible with today's ecosystem.

    If PQ fear i= s indeed such a strong motivating factor as you hypothesize, wouldn't this = be an argument against P2TRv2? P2TRv2 isn't quantum-resistant by default bu= t 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 address format= which requires a follow-up fork to be secure. 

    To borrow a phrase, P2TRv2 bears a systemic risk = (solving the fork timing problem), whereas P2MR has only local risk= (address reuse, which btw would also be solved if we could= solve fork-timing). Antoine drew this comparison on his post too but we ap= parently disagree on which is preferable.

    This indeed touches on a fundamental difference in viewpoin= t.

    I believe the primary risk in both a= pproaches ("Never" and "Later") is systemic! Bitcoin either as a whole m= igrates to PQC resistance, or not and everyone loses. If too many(*) vu= lnerable coins/users remain on Q-day, I believe the remaining options are all damaging for everyone, because a wide EC freeze may be necessary to remain relevant (who would use a currency where many coins are vulnerable to theft?), but doing so likely undermines Bitcoin's long-term value proposition (how does it differ from an native-PQC altcoin bootstrapped with some arbitrary subset of Bitcoin's UTXO set?). Individual users adopting a quantum-resistant wo= rkflow without an expectation that most other users will do the same is not= a migration strategy, but a hedge against Bitcoin's ability to meaningfull= y migrate in time. Yes, if available there will certainly be users taking i= t, but I'm not convinced it is beneficial for the success probability of cu= rrency-wide migration if a "Later" option is available too, and possibly wo= rse.

    The "Later" option does not have all the restrictions listed above, and = I believe has a chance of getting adopted in the medium term by everyone if= available with sufficiently low friction. That of course brings us to how = the expectation of a future EC softfork can be relied upon. And it is somet= hing of a self-fulfilling prophecy I think. If literally all PQC defense of= Bitcoin were to be done through one new output type, then it seems almost = a given that the EC disabling will happen in time: even if "Bitcoin" doesn'= t, someone will create a fork that does so in time, and if it's that essent= ial, that fork will win. A concern may exist about potential disagreement w= ithin the community about when the disable-fork should occur, but I think i= t's still a far better prospect than... essentially making Q-day a guarante= ed disaster apart from a few people that get to save their coins, if it hap= pens before the future feature-rich efficient PQC signature schemes can be = adopted.

    And if you accept that at least a "Later"= option is needed, I think adding more PQC options actually weakens it! If = some people have their coins in "Never" or "Now" outputs in a PQC-safe mann= er (subject to the restriction / costs those bring), then that reduces the = incentive to get the "Later" narrow EC freeze to occur, and indirectly redu= ces the value of that output type.


Users and d= evs can control local risk with very simple software tweaks (to avoid addre= ss reuse) but they can't do anything about systemic risks.

I think you're vastly underestimating what= is simple for most uses. Not sharing public keys or signatures with untrus= ted parties is a wildly different world than we have today.

T= his is why I prefer P2MR. If the fork-timing problem can be solved conclusi= vely then maybe P2TRv2 would be viable, but as you've alluded to, we have y= et to hear any passable solution that doesn't require a cooperative CRQC.

=
I think it has a much= higher chance of getting ~everyone on it in time, even if there is no cert= ainty.

I lack data, but I s= uspect that by Q-day most coins will have some knowledge-= asymmetry with a CRQC (hash preimages, BIP32 parent keys, hidden P2TR scrip= t paths, etc) and so can be rescued with simple commit/reveal protocols - n= o heavy ZK machinery or hard-forks needed.

I don't understand this, can you elaborate? Having a knowl= edge-asymmetry seems like something that matters for ZK machinery.

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

I think anything relying on BIP32 recovery is disaster-recovery terr= itory, not interesting migration, because it'll inevitably be an arbitrary = subset that survives. It's something people can think about of course for u= se in case of a Q-day before migration to PQC-safe outputs at scale happens= . As I've argued, that's probably an uninteresting outcome for everyone. Pe= ople will want to do what they to save what remains, but I don't think it s= hould really matter in this discussion today.

Also, It sounds like you're really saying that the systemic migration to PQC is som= ething that=20 will happen through a commit/reveal, not through what we're=20 discussing now. So what is the point of having something like P2MR or P2TRv= 2 in the near term?
=

On a more positive note, if we ca= n someday say "Look, quantum computers appeared and screwed some people = over, but most people can recover their coins as long as they fulfill any o= ne of these common criteria," then that seems like Bitcoin's unique val= ue and confiscation resistance is surprisingly intact to me. Certainly bett= er than certain other altcoin migrations I've seen in the past, but I guess= this is a subjective question, and everyone will have their own opinion.

=
Yeah, I have a pretty diffe= rent view here.

-- 
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/_z6_J= UmphCkUYvI6gemSFMD9Sb_rDL03IQbtZQCNlk6pmioGEQBir_gMyZCfticFa8Ttfc0xoFHdxR07= _MNuAfBu8do_h5IDf2apVk1w1BM%3D%40wuille.net.
--b1=_TfpXMTX68LcGm8KgUnUBOfBllkcsREoJm0okvDFUc--