> I just don't see a reason to do P2MR over just utilizing P2TR (or maybeP2TRv2).
>
> P2MR will *also* require an equivalent P2MR-disable-soft-fork
P2TRv2 means locking wallets into using elliptic curve code for as long as P2TRv2 exists, because you will always have to compute and verify the tweaked output pubkey. Future PQ Bitcoin wallet devs will see secp256k1 as we today see broken primitives like md5 or DES. Future devs shouldn't have to add legacy cruft EC libraries into their codebases when it's not even usable for cryptography anymore.
Even if you assume a second P2MR-disable-soft-fork will be needed (which is debatable), then it still pays to remove the inefficient and unnecessary cruft of EC crypto for the foreseeable post-quantum future. You might think of it as decoupling UTXO ownership from any specific public-key cryptosystem.
P2MR is strictly more secure since it depends on weaker assumptions. P2TRv2 is more complex for wallets to implement than P2MR, unless you count code reuse from P2TRv1. P2TRv2 is (marginally) computationally slower, and less block-space-efficient for script path spends. So who would choose P2TRv2 over P2MR?
The only redeeming factor of P2TRv2 is that it saves a few dozen witness bytes per input when using schnorr EC key spending, compared to P2MR spending. For low-frequency use cases like cold storage, that doesnt matter much. At current rates thats like 10 sats per input. For high frequency use cases where every vbyte counts like hot wallets, exchanges, mining payouts, etc, i have good news: P2TRv1 still exists and can be used just fine. You "just" need to make sure the coins are moved to a PQ address before a quantum computer attacks them. I'm assuming these high-frequency use case actors are online enough to take that last step when necessary.
Thus i see P2MR as the superior choice to P2TRv2 even if P2TRv2 may be slightly more space efficient in the near-term. Thinking longer term, P2MR is the better choice.
Thinking even further into the future, we have options for a sort of P2TR-style of address using isogenies, by hiding a commitment to a taproot-style script tree inside a public key curve (public keys in isogeny cryptosystems are represented by elliptic curves). Keypath spending would be via SQIsign (or other schemes). So don't worry, we are not stuck with only merkle trees forever. I'll elaborate more on this idea in a forthcoming article i have cooking on isogenies.
> ZK proof-of-seedphrase
If we were going to use a ZK proof to rescue quantum procrastinators, it should be proof of BIP32 hardened key derivation, and possibly also proof of pubkey hash preimage knowledge. This is strictly more general than a zero-knowledge proof of seed phrase, the arithmetization would be wayyy more efficient, and would recover more coins from more diverse wallet types.
Also, there is no need for it to be a hefty zero-knowledge proof, like a STARK. Rescue could be deployed using a commit and reveal protocol, as has been discussed on the list previously (sorry, i dont have the link in front of me right now). The idea is that a sender can rescue frozen UTXOs using a commit/reveal sequence of transactions which ultimately proves the sender knew a BIP32 parent xpriv (or pubkey hash preimage) which controls the coins in question through hardened BIP32 CKD, which a CRQC shouldn't be able to forge.
This would maximize rescue coverage while minimizing blockspace congestion, and could be done as a soft fork.
-----
I'm glad to see thoughtful discussion on the subject of how to handle a quantum freeze. But it is important to put this in perspective in the context of this thread: right now the number one most important thing - which we NEED to do if Bitcoin is to survive appearance of a CRQC - is to provide a standardized wallet address format which includes a secure fallback way to authenticate UTXOs if ECC is unsafe to use. We can debate about freezing or rescuing coins, or the philosophy of ownership, but these questions will not be decidable for years.
What is decidable is this: how would you change Ethan's proposal, if at all? I'll remind everyone that currently it is limited only to adding two features: BIP360 P2MR addresses, and SLH-DSA opcodes. Those two changes are all we need in consensus to finally give hodlers an option to migrate.
I've gone through and catalogued some of the feedback on Ethan's proposal. So far I've heard these material critiques:
1. Why not instead deploy covenant opcodes (TXHASH, CTV) and use them to implement commit/reveal?
As i mentioned in my last message i don't think that is possible, at least not using the technique Erik linked. I'd be happy to be proven wrong here because that'd be fantastic news if true.
2. Why not use SHRINCS instead of SLH-DSA?
Seems like a valid idea to me. SHRINCS would add implementation and UX complexity but it'd also make the fallback sig scheme scalable - a very nice property to have in the worst case scenario where a majority of users end up needing to sign with it. Philosophically i dislike statefulness in a cryptosystem, but maybe as a fallback it is an acceptable tradeoff.
3. Why not deploy GSR and let wallet devs roll their own crypto?
As ethan pointed out, this would be bad for standardization and interoperability, and also requires GSR to be deployed as a pre-requisite. If GSR is activated and in-script signing schemes are standardized correctly, it could possibly be a suitable alternative to activating dedicated SLH-DSA opcodes.
4. Why not continue using P2TR and disable keypath spending later, rather than adding a whole new address format?
As ethan pointed out, this depends on timing a future disabling soft fork correctly and will lead to FUD, avoidable debate, and confusion. It is also confiscatory, as it would freeze standardized keypath-only P2TR outputs which lack a script path.
5. Why not redeploy P2TR with a new segwit version number, which opts into a future keypath-disabling soft fork?
Ethan and i have both made some compelling arguments as to why we should give the community a new address format which is totally decoupled from any PQ-vulnerable cryptography. If the increased fees of P2MR are an issue for high-frequency hot wallets, P2TR is still viable, at least until Q-day. As stated Ethan's proposal is more motivated by long term cold storage use cases. I consider a small increase in witness size to be an acceptable tradeoff for (speculative) quantum security, and the costs of clinging to those savings in the near-term to be unacceptable. Key-path spending may be reinvented in the future using other novel cryptosystems, with another new address format that depends on new cryptographic assumptions.
-----
I apologize if i missed anyone's feedback notes in this summary. Please correct me if i have!
regards,
conduition