See more comments inline below.
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 improves another (relative costs w.r.t. P2TR in the common case). Even with both, the result is still worse than P2TR today in both aspects (key-based spend is still more expensive compared to P2TR, and the incentive for key-based over script-based spend is weaker within P2MR).
I want to take a step back however and separate the discussion into 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 / 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 opcodes disabled from the start).
Tweaking the commitment structure modifies the incentives of one over the other under some conditions, but I think the question of when/how the EC-disabling happens is the more fundamental one, and it is largely independent of the commitment structure. I'll go into more detail below, but my reasoning is primarily that the "Never" and/or "Immediately" options are just insufficient with current technology for any worthwhile migration attempt (independent 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 reasoning about which specific structure(s) are , and that is where taproot-based constructions come out ahead by having better incentives in the short- to medium term (the numbers above mean essentially less/zero economical friction).
I also 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 is no EC-disabling in it, then disabling is confiscatory.
There is one technical difference where the specific commitment structure matters: P2MR ("Merkle-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 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 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 share signatures with each with each other, of coins that aren't necessarily going to be spent.
- Not using Lightning.
- Not using silent payments.
- Not using escrow services (like Blockstream's or BitGo's 2-of-3 wallet services).
- Not spending fork coins / airdrops.
- Never reusing addresses.
Of course, with evolving technology and other developments, some of these
restrictions may weaken. Alternatives for some of these may be developed, but I don't think think fundamentally 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 solution is feature-rich efficient PQC signature schemes of course, but those do not exist today. If we want to start a migration in the 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 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 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 systemic! Bitcoin either as a whole migrates to PQC resistance, or not and everyone loses. If too many(*) vulnerable 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 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 available there will certainly be users taking it, but I'm not convinced it is beneficial 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 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 something 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 essential, that fork will win. A concern may exist about potential disagreement within 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 happens 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 manner (subject to the restriction / costs those bring), then that reduces the incentive to get the "Later" narrow EC freeze to occur, and indirectly reduces the value of that output type.
(*) = 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 "theft vs freeze" applies always seems like a win.
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.
I think you're vastly underestimating what is simple for most uses. Not sharing 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 conclusively then maybe P2TRv2 would be viable, but as you've alluded to, we have 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, even if there is no certainty.
I lack data, but I suspect that by Q-day most coins will have some knowledge-asymmetry with a CRQC (hash preimages, 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.
I don't understand this, can you elaborate? Having a knowledge-asymmetry seems like something that matters for ZK machinery.
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 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 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 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. People will want to do what they to save what remains, but I don't think it should really matter in this discussion today.
Also, It
sounds like you're really saying that the systemic migration to PQC is something that
will happen through a commit/reveal, not through what we'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 appeared 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 intact to me. Certainly better 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 different view here.
--
Pieter