I don’t believe there is a significant synergy here. I think wallet providers/services who are keeping up with technological advances will adopt PQC output types without or without CISA. Those who don’t, which will tend to be those with users who don’t care either, are the ones we have to convince. Unless we see very significant fee rate increases, I think they’re mostly immune to fee arguments, and won’t be swayed by CISA. (Perceived) complexity of adoption may hurt, however, though that is admittedly a weak point.
My main view is simply that CISA won’t help adoption, and is thus not worth the additional complexity of consensus changes. I don’t think it significantly worsens things, and I’m not against it, but I think it’s unnecessary and a distraction.
Neither P2TRv2 nor P2MR are a “quantum secure output type” in an absolute sense. As I pointed out before, all continued use of ECC has risks, and relies on an assumption that some entity will make a correct call about when to disable it. The only distinction between the two is that with P2TRv2, that does not include the owner(s) themselves. Given the arduous restrictions (no hardware wallets as we know them, no xpub/description sharing, …), I believe this isn’t a practical possibility for many if not most users to exercise that ability even with P2MR. Furthermore, I believe that the more interesting CRQC survival scenarios inevitably rely on large-scale migration and coordinated disabling in time anyway.
I understand the psychological appeal of wanting an output type that’s categorically not subject to ECC, or at least gives users that option, and lack thereof may cause some to panic. Having a separate, and possibly later-dated, separate P2QR or P2MR output type (with new witness styles etc) can fill that need. But for the long tail, my belief is that we ought to make something that is as smooth as possible to adopt, both in terms of technology (for developers/companies to provide) and not costing more (so users don’t refuse).
I really very strongly disagree with this line of thinking. Our goal as protocol designers is not to be able to claim we did enough by providing people a good option. Our goal is trying to design something people will actually use correctly.
I believe that it is a practical impossibility for many software and users to adopt workflows in which P2MR provides quantum-resistance, due to ingrained use of public key sharing. Claiming that it does provide that is at best ignoring reality to make your job easier, and at worst actively misleading people by providing a false sense of security. Shaming them won’t change that reality.
If they have that concern (whether justified or not), they shouldn’t use P2TRv2 at all, with or without CISA. In fact, if one has that concern they could be even more strongly against combining with CISA, as they shouldn’t want the extra incentive it may provide to others to adopt an output type that they perceive as risky.
I won’t deny that such users/developers likely exist, but I think for that the better option is providing a separate P2MR or P2QR type at a later stage. Not giving up on the P2TRv2 advantages that may sway much less sophisticated wallets/users to adopt.
Yeah, that’s fair. Though it has a disadvantage too: people may choose to adopt it in an “unprepared” way (without PQC path) because the output type has advantages beyond quantum protection. I don’t think that’s very likely unless we see a significant and persistent feerate spike, but it would be a pretty bad outcome, as it could lead to arguing against an ECC-disabling softfork, against deploying Miner Lockdown, or for disabling Tripwire.
The discussion you’re responding to here was in context of a new witness type which introduces a new discount. So the weight limit would be on the newly discounted cost.
The implementation is probably the easiest aspect of a consensus change. It is an aspect though, and I agree that CISA probably compares relatively favorably to any PQC addition.
I understand the apparent contradiction, but I don’t think the situation is comparable. That byte was in the transaction output, paid by the sender, not by the wallet adopting the change. We needed to avoid a situation where non-Taproot wallets would refuse to send to P2TR because it’s more expensive than all other existing address-enabled output types at the time. P2TR needed a new address type (BIP350) to be accepted by senders before real P2TR adoption could even begin. Getting rid of the extra byte made it as expensive to send to as P2WSH, which was already widely supported.
This is also in line with my argument against (just) P2MR: we shouldn’t give a reason for people to refuse upgrading because it makes things more expensive than they already are. I truly believe there is an asymmetry here: making things more expensive can have a stronger discouraging effect than making things cheaper has an encouraging effect. This is because there are multiple ecosystem entities involved in upgrades that all need to be convinced. It suffices for one to care about fees to refuse, while adoption requires convincing all of them.
Taproot was also not time sensitive in its adoption. I won’t deny that I would certainly have wished for faster adoption than we see today, but for getting Bitcoin quantum-ready I think we hope for a faster rollout.
That said, in retrospect I agree the complexity of saving that one byte was probably not worth it.
I imagine completely static per-wallet PQC keys, with no key derivation. Wallet descriptors move to store xpubs + static stateless PQC pubkeys or pubkey hashes (one per wallet/user/device), which is compatible with all of today’s use cases I can imagine. For very simple non-sharing non-HWW single-party wallets, an equivalent for hardened derivation is possible, which would be compatible (but still icky) with stateful signing. Longer term it may be possible to move to sharing complete sets of future PQC pubkeys, but I don’t think that’s for everything, and probably not realistic in the short term.
The privacy implications here are pretty bad after ECC disabling, but I think it’s the best we can reasonably see adopted at scale. And the goal is just avoiding disaster. Long-term, we’ll need PQC that’s compatible with homomorphic derivation, or so much time that the ecosystem moves on to entirely different approaches.
Absolutely. Any change requires extensive design and testing, even if it’s minor. But CISA does add more to it, a little bit without actual aggregation, and possibly quite a lot with aggregation (because signing is no longer per-txin thing, which may need significant redesigns).