> Yep, we absolutely agree! I just don't see a reason to do P2MR over just utilizing P2TR (or maybe P2TRv2). Here is my P2TRv2/ P2TRD vs P2MR analysis. Terms: - P2TRv2-disable-soft-fork - refers to the soft-fork that disables key spend paths for P2TRv2 outputs, but does not disable key spend paths for other P2TR outputs. - Q-day-long - The day at which long exposure attacks start happening. Set of outcomes for P2TRv2: Future-A: Q-day-long happens and P2TRv2-disable-soft-fork is NOT activated. Funds are stolen from P2TRv2 outputs, trust in Bitcoin declines. Future-B: Q-day-long happens and P2TRv2-disable-soft-fork is activated. P2TRv2 outputs are protected from quantum attacks. Set of outcomes for P2MR: Future-C: Funds in P2MR are safe even if Q-day-long happens unexpectedly. The risk of Future-A will be priced into the value of Bitcoin. We can reduce Future-A risk by activating P2TRv2-disable-soft-fork as early as possible. Activating P2TRv2-disable-soft-fork as early as possible is equivalent to activating P2MR. Thus, might as well activate P2MR instead. Do we want to tell holders: - Move to P2TRv2 and then trust us to activate the P2TRv2-disable-soft-fork in time - Or move to P2MR, you'll be safe. > Still, I think my point stands - in the face of many bitcoiners writing off the quantum threat, wallets aren't going to have a lot of incentive to adopt technologies that make things marginally more expensive. Maybe in 2027, but what about 2028, 2029? If we see steady progress toward a CRQC the drumbeat will become louder and louder and wallets will want to tell their users they are quantum-safe and secure against classical attacks on ECC. The first parties to move over will likely be big holders willing to pay a trivial increase in fees for security against existential tail risks. > I'm confused by this comment - a soft fork that disables insecure spend paths to avoid them being stolen is likely going to have a very easy time, not "fight an uphill battle"? soft-fork-1: Disables insecure key spend paths in P2TR. I don't have an opinion on the ethics of this, but the incentives are aligned to make this happen (reduces supply). soft-fork-2: ZKP proof of seed phase to allow people to safely spend from a disabled key spend path. The incentives are aligned to oppose this soft-fork (increases supply). The incentives support soft-fork-1 happening, but soft-fork-2 not happening. I don't claim to predict a future here, but the incentive issue here worries me. Other questions: Soft-fork-1 must be designed so that soft-fork-2 is not a hard fork, that seems doable, has anyone written up a plan for it? How big is this proposed PQ ZKP proof of seed phase? I've been assuming ~100kb per spend since we have to use PQ ZKPs. On Thu, Feb 12, 2026 at 9:56 AM Matt Corallo wrote: > > > On 2/11/26 5:57 PM, Ethan Heilman wrote: > > > For what its worth I do not see a scenario where a decision > ultimately made by the market will > > pick the fork side with materially, say 5-10x higher, supply, over the > side with lower supply... > > > > Completely agree, the incentives favor lower supply. I wouldn't want to > count on it happening and > > even if it does happen the freeze fork might not freeze P2TR. According > to the 2025 chaincode report > > [0] P2TR represents only 0.75% of total supply. > > I believe we're talking past each other, then. This was a side note - as > Jonas mentioned it seems > reasonable that a P2TR-based QC signature validation opcode could come > with an on-chain signaling > bit (i.e. a "Taproot V2" that is functionally identical but indicates the > presence of a QC signature > script path available). > > > > ~all wallets today use seedphrases, which could still be spent with a > ZK proof-of-seedphrase :). > > > > I'm all for putting ZKPs in consensus, but it seems unlikely to me that > it will happen. > > We just agreed that its highly likely that insecure spend paths are > disabled. I do not remotely see > how such an action could occur if the result is that a large number of > coins are seized. The only > viable approach way for that is to allow seedphrase-based wallets to > retain access. > > > It is better > > to make Bitcoin safe than promise safety that requires a future hardfork. > > There is no hardfork required here. > > > This is especially true > > since as you point out lower supply is incentivized, so a soft fork that > freezes coins would be > > fighting an uphill battle. > > I'm confused by this comment - a soft fork that disables insecure spend > paths to avoid them being > stolen is likely going to have a very easy time, not "fight an uphill > battle"? > > > > Hell, *any* PQ soft fork is going to see limited adoption in > "consumer wallets" until its > > urgent, hence why I think the community will be basically forced to > disable insecure spend paths and > > only > > allow spends via ZK proof-of-seedphrase. But at least something that > doesn't also 10x > > transaction costs might reasonably be adopted by default by wallets that > don't use seedphrases like > > Bitcoin Core. > > > > I disagree. If we get P2MR and SLH_DSA/SHRINCS the wallets can use > quantum-safe outputs (Schnorr OR > > PQ) with Schnorr as the default spend. The wallets can market themselves > as quantum safe. > > This flies in the face of the last 15 years of experience with Bitcoin > wallets. Yea, it sounds > great, but we've got 15 years of experience showing that wallets only > adapt when they go out of > business/stop being maintained and get replaced with new wallets (which > often ship with the latest > technology). Worse, many bitcoiners (maybe rightfully, maybe not) entirely > write off the quantum > threat - all the more reason they will simply not adopt any changes. > > > The cost > > in transaction fees to a user is small, a 1 input P2MR transaction would > only be 37 bytes larger > > when compared with a 1 input P2TR transaction. Those 37 bytes are in the > witness, so the real cost > > is ~10 vbytes. > > Apologies, I had understood the P2MR proposal to only feature PQC-based > schemes, rather than also > offering schnorr as an option, leading me to incorrectly conclude it would > be drastically more > expensive, rather than marginally so. > > Still, I think my point stands - in the face of many bitcoiners writing > off the quantum threat, > wallets aren't going to have a lot of incentive to adopt technologies that > make things marginally > more expensive. > > Worse, there's no real advantage here over just doing in the taproot key > path - because of address > reuse a wallet relying on P2MR + schnorr anyway will ~always have its > public key revealed so we > might as well continue relying on P2TR to save the 37 witness bytes and > get the same result (that > wallets can do something cheap with "just" a key derivation change and > explicitly opt in to a future > soft fork which disables the then-insecure spend paths). > > > Yes, if Q-day happens, time passes and then quantum computers become > powerful enough to perform > > short-exposure attacks, anyone needing to move their coins to an output > have to pay fees for an > > additional 8,000 bytes (SLH_DSA) or 324 bytes (SHRINCs). This is still > better than a PQ ZKP proof of > > the seed which would be between 20,000 to 120,000 bytes and more likely > to have a security flaw than > > SLH_DSA. > > Yep, I'm not proposing at all that we do nothing because a ZKP of > seedphrase is an option, rather we > should add support for SHRINCS and encourage wallet adoption. But at the > same time we should > understand that we're incredibly unlikely to see the kind of adoption in > time to avoid the need to > do something like a ZKP of seedphrase when the time comes. > > This is also probably the least interesting point of contention, FWIW - > this is a decision for a > future bitcoin community, not a decision for us to make today. > > > If efficient quantum signatures or compression techniques are developed, > we can and should adopt > > them. If they are efficient enough, they can become the default. This > proposal is designed to keep > > funds safe in the intermediate period while better techniques are > developed to cover the tail risk > > where Q-day happens before the technology we need to completely ready. > > Yep, we absolutely agree! I just don't see a reason to do P2MR over just > utilizing P2TR (or maybe > P2TRv2). > > > > No it doesn't - it requires a soft fork when the risk is imminent, > but it happening somewhat > > before that time is okay too. > > > > We might wait too long and misjudge the risk and Q-day happens before > the soft fork activates? What > > happens if freeze fork is activated but then 3 years pass and it looks > like a CRQC isn't going to > > happen after all? Now people who had their coins frozen are pushing to > undo the soft fork. > > > This approach carries too much risk from uncertainty and it was "the > plan" it signles that Bitcoin > > leaving things up to chance that don't have to be left to chance. > > > > Enabling people to opt in as early as possible enables the prudent to > protect themselves for very > > little effort and cost. Those people know their coins are safe and can > still use their coin as they > > did before. > > We agree. I believe your response is based on a misunderstanding of my > argument, hopefully clarified > above. > > > > I mean people can create invalid addresses today in plenty of ways. > How is this unique? > > > > P2TRD would be an address, which looks exactly like a 100% valid address > and which can be spend from > > like a valid address and hwoever at some future time, it may or may not, > become frozen. > > Sure, but this is still no different than any other P2TR script-path > structure - you have to test > things you use, even if you use them rarely, which is the entire point of > the P2TR design :). > > Matt > -- 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 email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BU673Q1U09Z_xrumiBjU9q9xKGnMOE3OC41Qt651g2ROw%40mail.gmail.com.