I fully agree with you that improving security and privacy and performance are worthy goals, though we’re living in the mere world of engineering where there is never a free lunch. Where I can be skeptical, it’s on the wallet and node complexity changes required to support CISA in itself.
More after that, there is a confusion to clarify first. Thanks to point that P2TRv2 does not address the critical security risk. A cursory read of the conversation made me first thinking that P2TRv2 *would* include support for a post-quantum scheme, be it sphincs, falcon or whatever, and that we we mere discussing the overall approach. So yes with this information in mind, a *naked* P2TRv2 sounds less interesting.
Now, even if we go to assume a *naked* P2TRv2, it does sounds to me technically possible to introduce discount for a future post-quantum scheme by introducing a novel witness scheme at the same time. E.g a BIP141 extension structure where the novel witness weight unit would be discounted from the 4 MB limit (I would have to verify the code paths in `CheckBlock()` thought at first we might be able to do so).
That’s a concurrent approach of CISA if the end goal is to incentive migration as much as we can, as in my view you’re making the point to justify that we bundle P2TRv2 + CISA. Now, about CISA while I’m supportive of the idea, the part where it’s unclear and where I’m a bit skeptical is on the half-aggregastion and full aggregation flow.
The BIPs say nothing about how it would be done in practice, if it would be done by the wallets only, with not special support from network full-node, or that for half-aggregation we would have magic mempool logic to enable this. This approach has been done naively in the past on some cryptocurrencies e.g Mimblewimble and it was the source of subtle privacy deanonymization attacks (remember discussing this one with Gleb Naumenko, and if we could have the same risk for bitcoin tx-relay network). If it’s wallet only for how the concrete aggregation protocol would play off, yes that’s another conversation.
More generally, in my position there is a bit off of soft-fork pessismism. If we go to take changes that are argued for fixing security issues, post quantum ones are far to be the only ones (e.g BIP 54) and realistically for post quantum changes we might need multiple soft fork changes spread on multiple years, to make the Bitcoin network as robust as we can.
Even if I see your point in the fact that CISA might incentivize the migration, the change in itself is for pure privacy and performance reason, and in my subjective scale of value, I’m not ranking it as importantly than soft-fork changes justified for network security. Beyond, we should still strive for a high review standard for any consensus change and have a lot of people partaking to the design and review / testing process of any change. Can we say we have more skilled eyes that have partaked in BIP 54 design and implementation process than we had for Taproot / Schnorr.
In my impression of someone who have seen the two I’m not sure, and in pure terms of social dynamics one we should keep the technical surface as much reduced as we can for post-quantum change. Somehow, it’s one the first consensus change in modern Bitcoin history, where the constraints are coming from a timeline which is “exogeneous” to us, than purely “endogenous” to the Bitcoin community.
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).
Finally I’d like to suggest we consider replay protection, from the start.
Any activation earlier than the tripwire, or some other deterministic mechanism, is going to be controversial. And it seems inevitable that some group people will emphatically want to freeze existing coins (<v2), while another group emphatically not, and others ambivalent. If such a fork is unavoidable, adding a (simple) replay-protection mechanism seems reasonable.
The reason to do it from the start, is because hitch-hiking with a new SegWit version offers the largest possible design space. Second shameless plug, see e.g. Universal opt-in replay protection? - #11 by sjors .
Is it possible to design a v2 SegWit such that CISA can soft-forked into it later, rather than needing yet another version bump? From a user-experience point of view, once their wallet adopts CISA, it can gradually migrate coins over to it, in a way that’s not noticeable / distracting. And of course the anonymity set doesn’t need to splinter again.
Update: we could allocate 1 bit of the public key to mark it anyone-can-spend, with the later CISA fork using that as the opt-in all wallets set it by default (regardless of support). This “just” means extending the existing x-only grinding mess by one more bit. Or, we could add a byte, get rid of x-only keys, and use the remaining 7 bits as flags. Neither helps with the anonymity set , and moving forward such a flag would likely reveal wallet capability.
Indeed. It boils down to a way to add segwit subversions. Either at the expense of making every output 1 byte larger, or extra complexity due to having to grind an extra bit. Neither is hugely appealing.
Sorry for the confusion there. i wasn’t suggesting naked P2TRv2 - I think that’s a bad idea, because it’d be unsafe to use due to the risk of later confiscation via tripwire. I was pointing out that P2TRv2 is not actually quantum-secure unless key-spending is disabled punctually later.
@fjahr can correct me here, but I believe half and full agg should be done by signers, either interactively (full agg) or non-interactively (half agg). I don’t believe relay nodes are expected to do any half-aggregation themselves. They would see unaggregated half-agg signatures as invalid when checking a transaction. Though it’d be very easy to write TX broadcast middleware that aggregates half-agg signatures, if they can be identified.
Agreed, but let me add: Our goal is to design something people will use correctly AND which effectively secures their coins. P2TRv2 is easy to use “correctly” but even with correct usage your coins are not necessarily safe. With P2MR, perfectly “correct” usage is harder, but has meaningful impact on security.
I think you’re overselling how hard this is?
if i just use a regular single-signer phone or desktop wallet, all my wallet has to do is (1) not reuse addresses and (2) not transmit my xpubs off-site. With all the light node tech out there now, and AI to speed up implementation, it’s never been easier to manage, and it’ll keep getting easier.
But OK, maybe for some low-effort wallets, or complex use-cases like hardware wallets and multisig, that stuff will be more in difficult. In truth, we have no evidence one way or the other to predict what wallets will or won’t do with their EC pubkeys in P2MR (unless you have a crystal ball?). A lot depends on the new HD wallet standards that nobody has fully spec’d out yet. It’s unknowable.
What we can say for sure is that however “leaky” P2MR is or isn’t when put into practice, P2TRv2 will be at least as leaky and almost certainly worse, because 100% of P2TRv2 EC keys are exposed from the get-go.
With CISA in play, i feel like we can accept that insecurity as a trade-off in exchange for the better classical performance, and as a hedge against CRQCs maybe never appearing.
Without CISA though, the efficiency gap between P2MR and P2TR is tiny: smaller than the gap between P2WPKH and P2TR (see next paragraph). This is why I don’t buy your argument that P2MR’s inefficiency compared to P2TRv2 (without CISA) would be a dissuading factor for any meaningful number of users, and it’s why my preference shifts firmly back to P2MR in this case.
P2MR is more expensive than P2TR yes, but most people don’t use P2TR, and those who do are typically early adopters who will more readily adopt a PQ output type (and/or CISA) if it were deployed anyway. Most users in the “long tail” that you’re concerned about, and PQ-cautious users like myself, use P2WPKH.
P2MR can be cheaper than P2WPKH. With @fjahr’s CISA or @starius’ EC recovery implemented on top of P2MR, then P2MR is actually more efficient than P2WPKH which is what most retail wallets are using today. The double-whammy of P2MR+CISA specifically is almost as efficient as P2TR for many-input transactions. P2WPKH users actually stand to reduce fees by adopting P2MR with classical optimizations, and they get plausible quantum security to boot.
So the class of users you’re concerned about in this argument seems tiny. You’re talking about users who (1) hold funds on P2TR, and (2) run wallets that aren’t well maintained, and (3) are steadfast opposed to paying a few percent more per TX even in exchange for quantum security. I would guess the pie slice that your argument optimizes for is smaller than a rounding error, and motivating that tiny minority of users doesn’t meaningfully move the dial on maximizing migration for the whole network.
“No key derivation”? You mean ephemeral, randomly generated PQ keys? That would make wallets unrecoverable from seed phrases. No, we’d need to derive the PQ key from something deterministically linked to the user’s seed phrase.
Most obvious would be to derive the static key from the seed phrase directly (no intermediate BIP32 step) using something like HKDF or HMAC.
But then, if you can derive one key that way, why not derive many? It’s not hard to do. Boom, we’re already defining a new multi-algo multi-key wallet standard.
There’s no way to save effort here that doesn’t compromise security. So we might as well do the work once, correctly, so we don’t have to do it again later. It doesn’t have to be complicated.
Actually it is possible to deploy P2TRv2 with a time-based upgrade hook that transmutes P2TRv2 outputs into anyone-can-spend after a specific deadline block height T (e.g. 10 years after initial flag day). We then have to commit to deploying a 2nd soft fork that enforces new rules for P2TRv2 at block height T to avert the mass chaos.
If CISA is ready by height T, we could deploy CISA as a soft fork. If CISA isn’t ready in time, we can kick the can down the road by extending the existing rules for another X years.
Same idea can also be applied to enable patchable SNARK systems, patchable signature schemes, or a number of other forwards-compatibility and engineering agility tricks.
To those against CISA today: would you at least consider putting in an upgrade hook like this so we can activate it on P2TRv2 in a few years if QCs don’t work out?
Because they’re two radically different proposals with radically different motivations, that’s all I meant.
I guess (but am not sure) that this relates to @fjahr 's :
I see this as (very vaguely) analogous to old discussions about cryptographic blinding on blockchains: as written down in a theoretical paper, combining X and Y together may not affect security property Z, and you can even prove it. But the real world is not like that sometimes : sometimes the way you put the pieces together has unexpected side effects. Homomorphic commitments to amounts is balance preserving, mathematically, but that doesn’t mean you don’t introduce risk factors.
Some people would want a CISA soft fork, but not the PQC one (or want a different PQC one). They might be orthogonal elements of a proposal on paper, but might not be in practice. This line of thinking is not exclusive to CISA of course.
Indeed, it would/will be more complicated to do separate changes instead of combined ones. I don’t think that should affect choices about proposals though.
…
Sorry for answering late, I thought we’d stopped talking about CISA, and anyway the conversation has moved on … quite a lot
It is correct that the BIP specifies how signers produce their signatures and how those get combined, but it does not make rules about who runs the combining step. I don’t think it could even do that if we tried, it is outside of consensus and a P2P protocol/application that does this could not be prevented by the BIP. But I don’t see why anyone would build it, because there is basically nothing to gain. Half-agg is explicitly opt-in, each signer commits to the aggregation mode already in its signature message, so a node could only ever aggregate signatures whose creators already chose to aggregate. Those signers can combine their signatures themselves, it is a cheap operation that any of them should be able to run before broadcasting and they already have done some integration work for making the signatures anyway. A node would just be doing the same work a little later but it also wouldn’t have the data to do it without a P2P extension or something similar: the s-values of the individual signatures never appear in the actual transaction, a member witness only carries the nonce share. To do anything, nodes would have to receive the full signatures through this new P2P protocol and the mempool would need to accept and hold transactions that are not valid yet. That is a significant change for no conceivable benefit. The situation in Mimblewimble was different, there aggregation across transactions (“cut-through” if I remember correctly) during relay was part of the protocol explicitly. Here aggregation is within one transaction and happens before broadcast.
That’s correct. Broadcast middleware that aggregates would need the full signatures handed to it out of band, e.g. in PSBT fields, since they are not in the transaction as explained above. At that point it is simply the aggregating party as described in the BIP, not really something that makes sense as a network service.
I did spend some time initially thinking about if allowing for any kind of aggregation by third parties but I couldn’t find any significant upsides that would result from this and could justify the additional complexity. And I think this decision works well with what is being discussed here: The best case for a third-party aggregation would be if the BIP341 signatures were not actually protected as an opt-out but could be aggregated despite the signer/wallet not even being aware of CISA. This is prevented with the explicit opt-out rules for these signatures which works well with a potential second reason that motivated adoption of the output type, like the PQC stuff discussed here.
Yes, in a vacuous sense, because it is so hard that it’ll be impossible to get most users to do it. You cannot expect people to stop reusing addresses, because it doesn’t fall within the purview of software that protocol designers and developers control. Address reuse is something humans do, and remains possible as long as addresses exist as shareable strings. Getting rid of that requires migrating to different approaches, like payment protocols. I tried 15 years ago, in what motivated the BIP70 payment protocol to be developed. It never took off, and was abandoned. Addresses, and their ability to be reused, is so ingrained in how Bitcoin (on-chain) payments work that in my opinion the only realistic way to avoid it is having everything and everyone move to a different layer (like Lightning’s BOLT11 invoices / BOLT12 payment codes) where the need for compatibility does not exist. I don’t think this is feasible in the timelines people are thinking of for CRQC, and probably needs decades.
Yes, it’s possible. But most users won’t, and not recognizing that is not responsible design.
(This ignores that just using “correctly” is not enough; the user also has to actually still switch to the PQC path in time, which most users are not particularly well placed for either)
This isn’t a software problem; it requires workflow/social changes and reimagining how people use Bitcoin.
They’re certainly more complex, but they are very important use cases, used by large amounts of users. And in particular for hardware wallets, by users who are likely not keen to touch their coins.
I really don’t understand this. What is your goal? If you view P2TRv2 as insufficiently secure, why would you want anyone to use it, and worse, incentivize it with CISA? If you’re okay with the security of P2TRv2+CISA, then none of the worsened security arguments ought to apply, with or without CISA.
(1) would be users who use P2TR or would be migrating there anyway the next few years, which I expect to be a substantial portion. In terms of users (but maybe not in terms of BTC), I think most are on software/providers (2) that aren’t particularly up to date (think exchanges, multi-coin wallets, …). And (3), don’t you think that many users would hesitate if they see a “migrate to PQC wallet? everything will become a bit more expensive once you do”?
My goal isn’t motivating, I wish we could but I don’t think we can. I want to remove friction that may stand in the way of adoption. Fee increases may be one of them. Another big push, post P2TR, to yet something else, may also be one of them.
Sorry, I meant no per-address derivation. The actual PQC key would obviously be derived from a hardware-generated or provided seed still.
Because it requires workflow changes, not just software changes. Large amounts of keys cannot be reliably written on a piece of paper or a metal backup. They may not fit in a QR code. They may not fit on a tiny hardware screen for manual comparison. A push towards “bag of preshared keys” may work in some settings, but there will be many where it just won’t. You need to deal with those too.
Changing how humans do things is the hardest thing.
I don’t consider that acceptable. You’re proposing an output type that, barring a future consensus change, automatically becomes insecure.
I’m aware that is not practically different from the appearance of a malicious CRQC prior to a tripwire triggering, but there it is an inevitability we’re already facing. Adding a guaranteed time-based one just in order to be able to get a neat upgrade hook seems like entirely the wrong trade-off to me.
I understand the appeal of killing two birds with one stone if we are introducing a new output type, but i agree with Pieter that P2TRv2 and CISA pull in opposite directions. Not only in terms of features, but also in terms of expectations. I don’t think CRQC-skeptic CISA enthusiasts would accept an expectation that their EC spending path becomes unspendable before CRQCs materialize. If so, this would at best lead to them not adopting it, and at worst would undermine the expectation of an EC disabling.
On the other hand, it may be that the lack of CISA support hinders migration to P2TRv2. The alternative of the P2TRv2 and CISA soft forks advancing in parallel also presents the possibility that CISA becomes available or gains traction before P2TRv2. It is admittedly more of a stretch, but this scenario could result in misaligned incentives unless P2TRv2 also supports CISA.
However, i am skeptical this scenario would result in a systemic risk, because P2TRv2 targets wallets / service providers different from those likely to adopt CISA. And those wallets / users likely to first adopt latest technologies like CISA are not the primary targets of the P2TRv2 strategy: they are paying attention to developments and are able to move more swiftly if/when CRQC risk increases.
They would however keep using distinguishable output types until then, which may be forever. So an argument for bundling the two would be to avoid this footprint. If Bitcoin users desire CISA, and there is a push to get the vast majority of utxos to use P2TRv2 on the basis of CRQC risk mitigation, it’s would be quite the missed opportunity that they be separate output types. That’s a lot of if’s though.
Regarding the fee savings, i too don’t expect the ~5% off for the vast majority of users to have much of an impact on the wallet developers’ decision to migrate to a new output type. Of course i agree savings become non-trivial where interactivity is minimised and input count maximised, as in the example of an exchange. I don’t think this makes much of a difference for P2TRv2: exchanges would migrate to it with or without CISA, because it’s already no more expensive and because it would keep them safe if/when CRQC risks materialize.
Regarding the plan, i (unsurprisingly, we’ve discussed this at length) largely agree with Pieter’s.
I believe Tripwire without miner lockdown is a non-binding constraint and as such does not really provide “teeth” to EC disabling, outside of a psychological effect which may help bootstrap the collective reliance on EC eventually being disabled (which is, in my view, the real “teeth”).
I think the major challenge with EC disabling is to prevent it from happening too soon. A premature disabling would undermine the individual (lack of dis)incentives to migrate, and thereby the PQ migration. Miner Lockdown, while it gives the collective of miners the ability to (i believe irrationally) trigger it prematurely, may help in reassuring those stakeholders who might otherwise push for an early disabling out of fear of an unexpected CRQC breakthrough.
I think risk mitigation (P2TRv2 + Tripwire) and full migration (P2MR + eventual EC disabling + Witness style) should be provided in separate deployments. Most of the complexity is concentrated in the latter, which is also the least pressing. It can also be argued that the full migration path should only be made available once we have a higher degree of certainty that CRQCs will become a reality, while the risk mitigation should be provided regardless. We may also learn things from the deployment of P2TRv2, and a couple more years of development in PQ land, that could be applied to the later deployment of P2MR.
The values in the table look correct to me, but i don’t understand the inclusion of the orange threat model (). Under these assumptions, why would you ever use the PQ spending path? That would make even today’s P2WSH “secure”. I don’t think that makes sense.
While you obviously cannot strictly control address reuse in general, there are major use cases where address reuse is perfectly controllable and manageable. Crucially, address reuse is not a problem for properly managed long-term holding addresses, simply because address reuse per se does not cause funds to have an exposed public key, only address reuse of an address that has previously been spent from does.
I think the point here is that P2TR and P2TRv2 are both clearly a regression from a PQ perspective compared to P2WPKH and other address types with hashed keys, until/unless ECC spending is disabled. As such, moving such funds to P2MR rather than P2TRv2 would certainly feel less risky to someone who is informed about the potential threat of a CRQC. Whether it would matter in practice to keep those funds safe if significant parts of the coin supply end up getting stolen is a different discussion, of course.
As a bit of an aside, since it’s come up I can also briefly elaborate on why P2TR “failed” from my perspective:
For the “taking payments” use case, it largely comes down to wallets and (especially) exchanges being excruciatingly slow to add support for sending to new address types. While I would love the ~20% savings on consolidation transactions, I still see people needing to use legacy P2SH-segwit to make payments, even NINE YEARS after bech32 was introduced. Adding yet another address option to the mix would simply confuse end users who aren’t generally crypto-savvy.
For the “holding funds” use case, P2TR is more expensive for both one-input/two-output and two-input/two-output transactions, loses the inherent PQ resistance of P2WPKH, and has a much smaller anonymity set. It therefore seems like a strict downgrade unless you specifically need tapscript.
I don’t think this is specific to CISA users though. Adoption of P2TRv2 generally hinges on people trusting that the disabling triggers will work as intended, not too early and not too late, and that is the same for every user. If the disabling triggers worked perfectly (only happens magically in the exact moment the first CRQC comes into existence), adopting P2TRv2 should be an absolute no-brainer compared to the other output types discussed here. If people believe they are too risky, P2TRv2 likely won’t reach consensus in the first place, with or without CISA. You mention further down that getting the disabling timing/incentives right is the hard part of P2TRv2 as well.
I personally agree, and think we should treat and identical, because their difference only matters under a tenuous condition (no address reuse/pubkey sharing), and then depends on an unknowable hypothetical (CRQCs being slow). But since these conditions are both things have brought up regularly in discussions, I felt it appropriate for completeness to treat them as distinct security assumptions.
That’s fair. But I also don’t think these are the target audience for P2TRv2. If they’re properly managed they can migrate in time to a later P2MR output type too.
Yes, of course, and I recognize the psychological appeal of an output type that doesn’t have conditions attached (which is part of the reason for favoring also adding a later-stage P2MR output type in addition to the long-tail P2TRv2 one).
But my comment here was more meta. Namely, why is it that (to @conduition) whether or not P2TRv2 has acceptable security have anything to do with its price of usage? Why is CISA relevant in this context?
These things should be debated separately. Either the security of P2TRv2 is acceptable to the ecosystem, or not. And maybe adding CISA to it (or to P2MR) is a good idea, or not. But I do not see why they interact. If CISA truly does make P2TRv2 more appealing (which I’m skeptical of), that shouldn’t be a reason to let it compromise on your sense of security about it.
I don’t think it’s possible to accurately predict what portion of users will or won’t have exposed pubkeys on Q-day. You think “most users” will be exposed anyway; I think (with education and smart wallet design) the fraction exposed would be quite small. Neither of us can really prove our arguments on this axis of the debate. All we can say for sure is that P2MR would protect some unknown fraction of coins from long-exposure attacks.
The question is, is that juice worth the squeeze? You think no, because you estimate the protected fraction will be low. I think yes, because I think the protected fraction will be high. Without evidence I’m not sure how we can resolve this question.
First, workflow/social changes will be needed either way. If Q-day happens, it’d be a complete paradigm shift in the world of cryptography. Drop-in replacements for existing workflows do not yet exist, so we can’t afford to shy away from changing workflows.
Second, this is a software problem. There are ways to do almost everything we’d need to, they’d just require some (reasonable) compromises.
Examples:
Wallets don’t give out xpubs freely anymore, they only offer addresses.
Wallets warn users about coins sitting on addresses whose EC keys are exposed.
QR codes can be animated to store more data. Cashu uses this technique today to transfer many kilobytes of proof data across a visual channel. Or a static QR code can encode a URI to load E2EE data blobs from an untrusted server.
Short-term multisigs can use musig/FROST as they do today, as long as the keys are retired before Q-day.
Long-term multisigs between untrusted parties can use hashed keys in script. E.g. OP_DUP OP_SHA256 <H(pk_1)> OP_EQUALVERIFY OP_CHECKSIGVERIFY ... OP_DUP OP_SHA256 <H(pk_n)> OP_EQUALVERIFY OP_CHECKSIG
If one really needs full EC functionality and is OK with accepting some short-term risk, they can expose their EC pubkeys to do whatever it is they need to do, as long as they move the coins to a fresh secure address before Q-day. But honestly in some cases like silent payments, it may be better to just abandon the feature due to the unavoidable risks involved.
And if devs or users screw any of this up, it’s still not the end of the world, because the EC disabling fork may happen in time to save everyone.
i think PQ hardware wallet security under P2MR is completely doable. A bit harder than today yes, and with a slightly different thread model: If you are using a hardware wallet to spend via EC, you have to assume either (1) the host device is not controlled by a quantum adversary, or (2) the EC disable fork happens before the host device has a chance to collude with a quantum adversary. Still, completely surmountable, and better than P2TRv2.
My goal is for Bitcoin and its users to survive Q-day with as little technical and economic damage as possible.
I believe CISA’s efficiency would significantly help move the needle on migration to a PQC-enabled address type, while also making the address type easier to argue in consensus by pleasing PQ bulls & bears simultaneously. I figured you guys would actually be all over CISA as it effectively provides a pre-written vehicle for P2TRv2 - just add PQC and a tripwire. Clearly i was wrong
I don’t necessarily view P2TRv2 as “insufficiently secure” as an absolute. I believe that the benefits of P2TRv2 compared to P2MR (drop-in compat, 8vb efficiency gain) are negligible compared to the existential risk of all the P2TRv2 coins being exposed on Q-day. CISA changed that calculus for me, by offering way better classical efficiency, blowing P2MR out of the water, which gives a new political factor that neither P2TRv2 or P2MR has: it can please PQ-skeptics, which is the class of user i am most worried about, second only to offline users who will need rescue protocols to reclaim their coins.
I’m by no means happy with encouraging migration to a PQ-unsafe address format. My stance is still that P2MR is the only truly post-quantum address format. P2MR would be needed too, to cover users with higher risk profiles like big institutions or HNWIs. But life is full of little compromises, and I figured this would be the perfect compromise in the interim to please all parties, as a first step on a larger migration path. Perhaps I was wrong.
Based on P2TR usage rates over time (in terms of either UTXO count, or BTC volume), it doesn’t seem like (1) is very large. I don’t know of a way to accurately predict what fraction of users are “migrating there anyway” so i can’t speak to that.
Re (2): Yes I agree that most users are using outdated software, but my point is that the venn diagram overlap between “slow-moving outdated software” and “P2TR enabled software” is slim, and that slim minority is who P2TRv2 optimizes for. Even if the “P2TR” and “outdated walet” sets of UTXOs are independently large, their intersection isn’t.
I do believe that a fraction of users will refuse a migration, but not because of fees. Procrastinators are probably either (a) offline or don’t update their software, and so never see any pop-up at all, or (b) quantum-skeptics who would refuse to migrate to P2TRv2 just as well as to P2MR, or (c) lazy/indifferent: The efficiency gap between P2MR and P2TRv2 is tiny compared to the absolute cost (tens of thousands of sats in some cases), privacy impact, and most of all inconvenience of moving one’s entire UTXO stack to a new fresh wallet. Of all the factors weighing on a user’s mind, an 8vb/input fee to spend after migration seems small potatoes.
Sidenote: the same argument applies to CISA as well: The savings from CISA may not easily outpace the economic or practical cost of migration. But CISA’s savings compared to P2TRv2 or P2MR are are much larger even in absolute terms, and would recoup the up-front migration cost much quicker than plain P2TRv2 could.
I think we may be picturing the same thing here in slightly different ways.
An upgrade hook’s deadline is significantly different from the Q-day tripwire situation. Q-day is unpredictable and requires proactive migration before it. An upgrade hook’s deadline is fixed, certain, can be deferred at will, and requires no migration (provided the upgrade is completed or deferred in time).
@fjahr is on the money here. I can and have used this argument against P2TRv2. If a user is skeptical of QC, why would she use P2TRv2 at all? Or P2MR? Both are strictly worse than existing formats, in a purely classical context. With CISA, at least some of these users have reason to migrate, and maybe some will even be foresighted enough to actually use a PQC leaf script.
The only way to incentivize PQ skeptics to use PQC is to make PQC more scalable than ECC, which is why i opened this thread.
Are you picturing CISA being deployed without PQC support? If P2TRv2 has PQC support via a new opcode or tapleaf version, CISA would inherit the same.
Or are you imagining CISA without an EC-disable expectation/tripwire? i think that is unlikely. Why would it be acceptable to deploy P2TRv2 with a tripwire, but not CISA? It seems a bit odd to me, to assume that because output type X is more “fancy” than output type Y, its users should have better adaptive security or agility and therefore don’t require this critical safety belt that output type Y has, and then bake that perspective into consensus.
I think we all seem to agree on a rough shape for the migration plan (yay!): first step should be simple and designed for mitigating risk and not necessarily for long-term usability; Second step should be scalable and thorough and usable, possibly using more complex cryptography developed in the intervening period. We just disagree on the specifics of what should go into each stage of the migration.
I’m still partial to P2MR (and/or CISA) + tripwire with a rudimentary hash-based PQC spending path as the first stage. Second stage should be a new discount (aka “witness styles”) and/or SNARKs, or sufficiently advanced and efficient native PQC.
It’s a complicated argument to bring through education, and wallet design only has a small ability to influence behavior: never showing the same address twice (which has been a best practice since 2009…). Beyond that, it could prompt the user “only hand this address out to one party and tell them not to use it more than once!”. But most users don’t read, and even if they do it may backfire: people might refuse to upgrade “because those new addresses can’t be used more than once”, if the more nuanced point (that other/existing addresses are also subject to it) isn’t made across.
Address reuse is entrenched, you need people to change behavior, and to do so, you need to provide a better workflow than the existing one (or make the existing one hard/impossible). You won’t, and without it I think it is very naive to think that documentation and education will make a dent here. You can even barely affect design decisions wallet and infrastructure authors make.
As for the bigger point of exposed fraction, address reuse is just one aspect. Any design that relies on sharing public keys or xpubs (with unhardened derivation) will need to change too. For some of those (but possibly a minority), that will be harder than changing address reuse practices even.
And of course, this distinction between P2MR and P2TRv2 only matters in cases where users are actually capable of independently deciding when to stop using ECC spend paths at the right time. If they don’t, there is no difference. You may say that their wallets can make that decision for them, but that’s not particularly far from requiring ecosystem agreement (users might leave wallets that decide before “everyone else” does so), at which point ecosystem-scale disabling (lockdown, separate consensus change, or even tripwire if CRQC is cooperative) may also remove the distinction between them. And all of that is conditional on the whole system not imploding over CRQC FUD before then still.
I think the distinction between the two (ignoring the possibility of a combination) is largely psychological. Perhaps that is on itself a good reason if it would affect adoption, I don’t know.
I believe my experience can be helpful here. But yes, ultimately we may need to agree to disagree.
I disagree. It’s essential to minimize the need to change workflows, because that will hinder adoption even more than the technical changes themselves. That doesn’t mean we shouldn’t work on new more PQC-compatible ones, but you can’t rely on changes happening prior to Q-day.
There may be situations where significant changes are inevitable, but for almost all use cases I can think of, they’re pretty small, as I pointed out earlier:
Key reuse, sharing xpubs, compact descriptors, … all remain fine (descriptors would store xpubs for ECC + static PQC keys). Software changes are needed, but users don’t need to change anything about their ways of interacting with it and with each other. It relies on timely ECC disabling, but as you know, I believe in practice most things do anyway.
How will you register a hardware wallet? Coordinate a multisig wallet? Those are the reasons for exposing xpubs. You need alternatives for these, and those require workflow changes. The user needs to do things differently; it’s not simply a software change.
Users and devs will screw this up, for all the reasons above and more. I think we’re much better off not wasting time trying to get everyone to change their ways, only to end up still relying on ECC disabling anyway.
This is perhaps the biggest vision difference between P2MR and P2TRv2 proponents. To me, we cannot rely on the ecosystem making the workflow changes needed for a security difference between the two to appear. We’re better off designing things that are to the extent possible drop-in replacements instead, for everyone, including P2TR users and prospective ones, to avoid resistance in upgrading.
I’m not sure about how valuable that is as a security model. If an adversarial CRQC exists, and an attacker that breaks into your software wallet, why wouldn’t they conspire and split the gains? And if no adversarial CRQC exists, none of this matters, and if you don’t worry about an attacker breaking into your software wallet, why are you using a hardware wallet / signing device?
Of course, this may not be economical if the CRQC running costs are high per key. But this applies equally to setups without hardware wallet.
EDIT: scratch that. If you assume a lower bound on BTC amount exposed on a key exists below which CRQCs are not economical, and your hardware wallet controls less than that, it is not inconsistent to assume the software wallet attack won’t collude with the CRQC, as the HWW is still interesting to protect against classical attackers.
Yeah, I understand. My perspective is really that we need to minimize change, as we can’t rely on economic incentives to matter in the short-to-medium term. They might, if persistent and significant mempool congestion reappears, but I don’t think that’s likely enough to rely on in the timeframe we need it.
But is it negligible compared to the difference in existential risk from exposure between P2TRv2 and P2MR? To me these are nearly identical, so any reduction in friction in adoption is a gain.
I think the mixed messaging makes it worse in this respect. Is it an attempt at making PQC secure, then why is it adding an optimization that increases reliance on ECC? Is it an efficiency improvement that sneaks in a PQC upgrade, then aren’t you worried about people using it without PQC path, undermining the planned ECC disabling plan?
Also, and perhaps I haven’t highlighted this enough before: I consider the focus on reducing byte size an artifact of the weight formula established by SegWit. This made sense in the past (i.e., with Taproot) as introducing new witnesses with new discounts would be a difficult upgrade (far harder than an initial P2MR or P2TRv2, probably even with CISA included). But in the longer term, I think a post-CRQC world will demand it anyway, and if we embrace that, most of the advantages of CISA (at least halfagg) can be had with just a better formula that accounts for batch validation costs. This makes it also less appealing to me to stack it in with P2TRv2.
I really wish you would stop saying that. It’s unambiguously stronger in this regard, but it comes with so many conditions that’s very misleading to think of it as “truly quantum-resistant”: it needs users capable of deciding when CRQCs might exist, curated workflows that avoid exposing public keys, lack of address reuse, and even Bitcoin as a whole surviving for it all to make a difference.
You’re right, and it’s wrong for me to focus on the long tail of slow-moving software for this part of my argument. They matter of course, and I think the existing availability of tooling/libraries around P2TR probably makes P2TRv2 probably very slightly easier to adopt for them than P2MR. However, my “increasing fees may turn away users” argument does not apply to those who are are on pre-P2TR output types still.
That said, the new output type(s) we are designing here is/are for everyone. Having (just) P2MR as PQC upgrade path is asking the ecosystem that adopted P2TR as a softfork, its users and prospective users, to choose between P2TR’s advantages and PQC. I think that’s a controversial choice.
I hadn’t, but it looks similar in broad lines. I’m imagining having the PQC pubkey be added at the output descriptor level rather than the xpub, as it’s composable (e.g. MuSig in the internal key across xpubs, and a recovery path with multisig over the PQC pubkeys), but for single-party cases it looks equivalent. So you’d have trv2(XPUB/.../*,[shrincs(PQCKEY)]) instead of tr(XPUB/.../*) now.
That is fair, perhaps I should have less optimism in this than I do. However, even with today’s usage, we still have roughly 2/3 of the coin supply protected by a hash (source). This historical precedent is why i think that, even without any effort to change wallet or user behavior, the fraction of P2MR coins that’d be covered by a hash on Q-day will still be significant and meaningful. If education makes an additional impact, even better.
Do you believe that people will reuse P2MR addresses more frequently than they reuse legacy addresses today?
I will point out that pubkeys exposed off-chain are significantly higher-hanging fruit for a CRQC. The attackers would have to collude with the holders of these pubkeys (e.g. wallets API providers, multisig participants, etc), of which only a fraction will be reachable, of which only a fraction will still have the pubkeys by Q-day, and only a fraction of those will be willing to defraud their peers/customers.
For a CRQC, the first prio will be keys exposed on-chain because of the comparative ease of target collection. Having fewer and harder targets even makes building a CRQC to attack Bitcoin less attractive to potential investors.
This is why i feel having an output type design that reduces on-chain key exposure in the lead-up to Q-day is a very critical step, even if it’s not perfect.
I agree with you that the challenges in preventing address reuse or off-chain EC pubkey exposure makes P2MR less attractive than it would otherwise be, with all else being equal, compared to P2TRv2. Yet, i still think that there is value in at least having some ability to keep coins secure entirely independent of the EC disable fork’s timing, and that value is measured on a completely different scale than the benefits of P2TRv2.
That’s a reasonable perspective. if the entire ecosystem of users and wallets are able to independently, organically recognize “hey, it’s too risky for me to use EC anymore”, then we might as well use that joint willpower to activate tripwire/miner lockdown.
However, this assumes that the transacting users subject to this argument are online and transacting at Q-day time, and therefore that they need to make that decision at all.
Typically the majority of bitcoins lay dormant, often for years at a time. So really the question a P2MR user must answer is not “Is today Q-day?” (which is the consensus-level question that tripwire and miner-lockdown must address, continuously and repeatedly); The question a P2MR user (or their wallet) must answer prior to transacting is “Has Q-day happened since I was last online?” That is a much easier question to answer: Tripwire, miner lockdown, and independent wallet providers can all make a significant impact protecting uninformed users in this capacity.
Reliably answering the latter (retrospective) question is not necessarily equivalent to reliably answering the former (reactive) question.
Of course, my argument here applies to mainly cold-wallet users, not to active transacting users like Lightning nodes, exchanges, bridges, and other hot wallet use cases. For them, they absolutely need to be able to identify quickly when Q-day has happened.
Sharing a large batch of addresses with the host computer suffices for a hardware wallet.
Long-term high-security multisig wallets can use scripts that hide EC public keys behind hashes. If addresses within a multi-address multisig wallet must be unlinkable, batches of such addresses can be constructed by sharing PK hashes up-front at setup time. If the multisig is short-lived (i.e. if it will likely be emptied before Q-day), then sharing EC keys between participants is totally fine and you can even reuse today’s code.
One may worry that in such a protocol, bandwidth and storage requirements for HWWs and multisigs scale linearly with the number of addresses. But the linear scaling rate is still totally manageable: to store a million addresses from a HWW (far more than anyone ever uses), a host computer only needs to store about 33 megabytes of hashes. In a 3-party multisig with 1 million addresses, each party would need to store 66 megabytes of hashes.
These changes would be slightly less performant than today’s options, but totally doable with no meaningful change in user-level workflows.
You have a good point there, and it rewinds us back to the key question we keep returning to: “what good will P2MR actually do, relative to P2TRv2?” Not what “can” it do, but what “will” it do.
Ultimately i think that’s an unanswerable hypothetical. We’ve both made clear our opinions on this question, but as mentioned earlier, there is no hard way to prove either take is correct. Maybe neither of them are. Maybe nobody will migrate to either, so there is no difference at all.
What I can say for certain though, and I hope we can agree on this, is that having P2MR as an option for users reduces the harm in all potential outcomes, even in scenarios where barely anyone uses it properly. I.e. The fraction of people effectively protected by P2MR is non-zero. Even if you were to assume the worst-case scenario - every EC key used in P2MR is instantly uploaded to a public database as soon as its address receives a coin - the purely psychological benefit of offering a PQ output type that can be used securely (in theory) is meaningful, WRT to encouraging PQC adoption.
I don’t think pushing workflow changes is super important to this question. That’s not the problem that we need to solve today at this early stage. The problem is designing a system that enables workflows to be secure in the future. In this capacity, P2MR does everything P2TRv2 does, and some extra on top. Even if those workflow changes are challenging, unlikely to be used, etc, none of them are outright dangerous, so having them around as an option benefits everyone.
To answer your question directly, my answer would be “because we don’t even know yet whether Q-day is really going to happen, so it makes sense to hedge our bets.” If Q-day never happens, we’d be glad to have CISA. If it does happen, we’ll be very glad we have PQC.
That’s fair, and i’m on board with updating the weight system if we end up needing to. Heck, i’m on board with far more invasive changes like SNARKs, with the aim of keeping blocks physically smaller as well. But if we are trying to work within the bounds of what we have today for a short-term upgrade, CISA offers the clearest path to an address type that is cheaper to use than taproot, without the complexities and controversies of new discounts applied to EC signatures. Plus it’s already written, and has other clear benefits to the network beyond fee cost (e.g. verifier performance).
Could you clarify what you mean when you say we could get CISA-like advantages after Q-day? Is there some (non-SNARK) batch verification mechanism of hash-based or other PQ signatures that you are referencing? i know of no such technology.
I suppose it’s mainly a question of definitions, but my view is that the output type and spending mechanism are distinct components. You can use a PQ-safe output type (P2MR) with a PQ-vulnerable spending mechanism (ECC). Or you can use a PQ-vulnerable output type (P2TRv2) with a PQ-safe spending mechanism (e.g. SHRINCS). If either is vulnerable, the construction as a whole is vulnerable.
I think of these as separate concepts but I recognize your point that some lay users may not understand the subtleties at play, and may just think of an address as being either PQ safe or not. So going forward i’ll try to qualify that statement more, regarding the additional need for PQC, or workflow changes. E.g. “P2MR is the only address format which, in concert with PQC and EC risk management, allows us to construct fully PQ-secure wallets.”
I’ll be the first to admit you’re vastly more experienced than I am in this domain, and so your predictions are far more likely to be right than mine, but really i think the possibility that we’re both totally wrong is huge. We’re both facing this superproblem and I don’t think either of us alone can adequately model the vast array of interacting complexities at play just inside our little brains.
The way to cover every scenario (i.e. to agree to disagree) is to deploy both output types simultaneously, which you’ve suggested previously, and let users decide what is more important to them: covering their EC keys with hashes, vs efficiency.
If I am right in my belief that devs/users value definitive security over efficiency/convenience, then coins will flow to P2MR. If i’m wrong, and coins distribute more evenly among P2TRv2/P2MR, then oh well, at least we’re no worse off in terms of security than if we had deployed only P2TRv2.
To me it seems like your argument thankfully doesn’t preclude deploying P2MR in tandem? P2TRv2 is still as secure and efficient and convenient as it would be if P2MR were not deployed at all. P2MR doesn’t necessarily need to be deployed along with scaling tech (e.g. witness styles, SNARKs, FancySig), as those could easily be added later with new leaf versions, or by making use of the anyone-can-spend depth-zero leaf.
This seems like the only remaining half-decent compromise i know of, given that the other middle-grounds (CISA and P2TRH) seem unacceptable to you guys. What do you think?
I strongly disagree with that. The credibility of EC disabling is self-reinforcing: the more people rely on it, the higher the guarantee it will happen. But there are design choices we can make that would impact its credibility, and disrupt this dynamic. One such design choice would be to encourage using the migration output type for a reason different from getting access to a PQ signing algorithm, because it would likely result in wallets or services being deployed that use the new feature but do not bother including a PQ spending path.
As you said yourselves:
This would substantially increase the probability of making EC disabling in P2TRv2 confiscatory, and therefore controversial, which could ultimately discredit the migration.
Of course, Miner Lockdown[1] improves the situation here. But the disabling remains nonetheless a future soft fork, that future users need to accept, and i believe we should not risk anything that could credibly compromise it.
P2TRv2 addresses the long tail of Bitcoin users who don’t even know what output type they are currently using. The way i see it, and i’ve seen advocated, the persons to be convinced would be developers of “mainstream” wallets.
They would start defaulting to P2TRv2 addresses, because it does not lose their users any functionality but hedges against a possible future in which CRQCs become a reality. Users would seamlessly start using P2TRv2 addresses (maybe only for change at first --see below), progressively migrating over the next decade (hopefully sooner for most of them).
It would be seamless because the emergency static PQ key can be derived directly from their existing mnemonics, and because there would be no additional gotchas compared to their current usage (such as syncing chain state through another mean than sharing their xpub with the wallet provider, or some EC pubkey-based functionality becoming unavailable).
I also think the biggest sources of friction here would actually be more mundane than what’s been discussed so far in this thread, such as a new address type throwing off users[2] or bech32m being incompatible with some services they currently use.
I disagree to disagree!
@conduition i believe this is an important one, which goes to the heart of our disagreement. It is true that the fraction of coins P2MR would ultimately protect is unknown to all of us. I believe it is wrong to conclude that we just can’t resolve the question.
Your position hinges on an extraordinary preemptive change of behaviour from Bitcoin users, at scale. I don’t think it’s correct to hold the opposite view to the same standard of evidence. On the contrary, it should be the default position unless we have strong reason to believe such a change will materialize.
But of course, a change needs to materialize for Bitcoin to survive a credible enough CRQC threat, and we only have a limited set of options available to us. So the broader question really is whether the set of conditions necessary for a P2MR-based migration to succeed is more reasonable than the set of conditions necessary for a P2TRv2-based migration to succeed[3].
Both options require the vast majority of users eventually migrating to it, so we can drop that from the equation. In the event that the vast majority of Bitcoin users migrated to P2TRv2 and the CRQC threat materialized, it’s almost inconceivable that EC disabling would not go through: virtually all economic actors who form the consensus rules of the system directly would depend on it. By contrast, it seems extremely unlikely that the vast majority of users would have never reused an address, never shared their xpub to other parties, or an online server to sync their wallet state, or used any other feature which otherwise assumes public keys are public.
It’s pretty clear to me an EC disabling in the migration output type will be necessary if we want to have any realistic chance at mitigating CRQC risks, but you may point out that such a disabling needs not be tied to P2TRv2 specifically. As we’ve discussed before, P2MR+EC disabling is also a possibility. It’s then tempting to see it as “the best of both worlds”, but i think that would be wrong.
I think P2MR+EC is inferior to P2TR+EC because it incentivizes[4] using the migration output type for purposes different from getting access to a PQ signature scheme (as per my argument at the beginning of this post), as well as preemptively breaks from the Taproot incentive structure (which i see as a major achievement in the past decade of protocol development). Additionally, it is also 10% to 15% more expensive to use.
Both issues could be addressed with witness types, as outlined in the second step of Pieter’s suggested plan. But that would be a much larger change, which i expect to also be more controversial. This better fits a later step, only happening if/after the CRQC threat becomes more credible, than a first, simple, non-controversial step meant to be available as soon as possible. But more importantly, there are just unnecessary, nice-to-not-have downsides, since an EC disabling would be necessary anyways.
I think there is also an argument for preferring P2MR+EC disabling. Since there is no objectively defined threshold for the number of users that need to be migrated, an increasingly credible CRQC threat could lead large P2TRv2 holders to push for early EC disabling. That could compromise the migration by turning P2TRv2 into P2QR too soon[3:1]. The psychological effect of hashing keys onchain before spending time may help avoid this situation. However, i don’t think this argument trumps the other ones above, and i still favour P2TRv2 as the first step of the migration.
Unlike, in my opinion, vanilla Tripwire which necessarily disables EC too late, and therefore can have at most a psychological effect. (Which may be sufficient, but is categorically different from the effect of a miner-coordinated disablement that is actually reachable in non-failure scenarios.) ↩︎
I’m assuming we’ve ruled out an immediate full migration (P2QR like) as an alternative, on the basis that not enough users would preemptively migrate to a far more burdensome output type to salvage the system. ↩︎↩︎
For all but depth 0 scripts, which i admittedly expect would have been the most common source of misuse. ↩︎
Yes, you’re right: If people choose to misuse a new output type by not adding a PQ-safe spending condition, their money could well be confiscated by EC disabling.
The same could happen with P2MR, or with P2TRv2. There will always be a practical incentive for wallets to switch to a new output type without adding PQC: appearances, marketing, etc. They can say “Look at us, we’re quantum secure!” without actually putting in the work to add PQC up front. Adding PQC is always disincentivized because it is complex, slow, and has worse features than ECC.
When EC is finally disabled, some coins will always be confiscated because it’s impossible to force everyone to use PQC, and inevitably some class of “PQ-clueless” users will probably fail to use the new output type properly. Doesn’t matter what output type we use. It’s a question of degree: How many coins confiscated? from how many users?
You do have a point that CISA makes this problem worse by adding a new incentive and thus muddying the waters with controversy. I don’t know by how much though, because anyone worried about their own coins being confiscated in this scenario can simply move to a PQC wallet - they don’t need to debate against EC disabling. And I think if we commit in advance to EC disabling (via tripwire), there should be no question that it will happen, so the only controversy will be around timing, and whether to give the “PQ-clueless” subclass of CISA users more time to migrate to wallets that actually support PQC. Do you see this being a realistic outcome?
Also keep in mind the other side of the coin: Consider users who don’t care about quantum and so won’t migrate at all otherwise. Their coins would eventually be stolen by a CRQC anyway if one appears. CISA incentivizes these users to migrate, and so helps offset this problem. What you really want to ask is, which is greater: the number of users who would use CISA without PQC, or the number of users who would not migrate to PQC at all without CISA? Personally i think the latter is larger, but again this seems like one of those unanswerable hypotheticals and i’m not sure it’s worth debating.
If users don’t even know what output type they are on, that’s all the more reason to argue for P2MR because to the lay user it’s basically the same as any other output type: it holds their bitcoin securely.
Influencing wallet developers to migrate their users is an admirable goal, but I don’t feel we should sacrifice the security of everyone else to pander to the lazy wallet developer subset.
I see your point that the additional safety requirements of hiding EC pubkeys with P2MR could add UX friction and so discourage devs from migrating. But as mentioned earlier in this post, if you extrapolate wallet behavior without changing anything from today’s UX patterns, we’d still have roughly 2/3 on-chain hash protection coverage. So i don’t see how migration to P2MR would be any less seamless than P2TRv2 in practice. Lazy devs will flout the safety requirements but that’s OK. Some wallets may actually make the effort to keep their users coins fully PQ-safe at-rest by cycling addresses, not publishing xpubs, etc, and the number of protected coins only goes up from there.
That additional layer of protection would have immense value to a lot of people, even if not everyone is perfectly covered.
I’ll add there’s also the risk that wallets may fix the witness version according to the encoding scheme, and so send to P2TRv1 by mistake. This would cause funds to be misplaced (but not burned). P2MR is worse off here, because funds mis-sent in this way would be burned.
FWIW I wouldn’t say it “hinges” on that aspect. P2MR is still more secure than P2TRv2 even if almost everyone misuses it. Granted, if people use it properly that’d be best and so we ought to encourage proper usage. My position is that some protection is better than none.
Besides that, as i mentioned in my previous reply, i have evidence for my belief that the fraction of coins protected (even with negligent usage) will be meaningful:
I will grant that perhaps the 2/3 coins which are hashed could have had their EC pubkeys exposed off-chain, and the same could happen again with P2MR, but as I mentioned in my prior reply, these are much harder targets than keys exposed on-chain, to the extent that a real-world CRQC may never have the time or capability to target them. This is security through obscurity, but still better than 0% protection.
What is your take on the timing problem?
I don’t think anyone here is arguing that EC disabling is unnecessary. My point is that P2MR makes the EC disabling timing problem less sensitive/urgent, by giving users a self-driven method to survive the chaotic interim period after Q-day, before EC disabling.
This is the scenario that I lose sleep over with P2TRv2.
We deploy P2TRv2+PQC.
Most users migrate.
CRQC suddenly appears, starts cracking and sweeping wallets.
Miners and core devs rush to activate EC disable but it takes days/weeks.
By the time we do, big stacks (e.g. coinbase, binance, US gov, etc) have already been swept.
In the interim period, nobody can react to protect their coins (except perhaps by sending to legacy hashed addresses like P2WPKH).
What would you do if you had your life savings in a highly liquid asset that is now open to theft without warning, and no idea when or if it’d be made safe? You’d sell it as fast as you could. Everyone else would think the same: We’d end up with a massive bank run. The big money players like Coinbase would be the biggest targets, and the most likely victims in the scenario above. They’d push for a hard fork to rewind the chain. I don’t think anyone wants this outcome.
Reconsider the above scenario with P2MR instead of (or in addition to) P2TRv2. In this scenario, everyone has a new option: to wait it out. Even users who weren’t using P2MR properly or at all still have the option (if they’re online) of moving coins to a new fresh address to protect themselves while they wait for EC disabling to take effect. Big bag holders (or at least a majority of them) would probably be using P2MR properly[1] and so are less likely to be victimized to the point of pursuing a rewinding hard fork.
Maybe some less knowledgeable users who reused addresses would be vulnerable, but isn’t this better than the scenario where everyone is vulnerable?
Can you really say that users’ material safety is less important than the abstract incentive here? If Q-day happens, and nobody’s coins (including yours) are safe, would you still be glad that we prioritized an incentivize above security today?
Would EC disabling really be meaningfully less likely to activate in the P2MR-flavored scenario? Who do you believe would argue against it?
If your concern is that “everyone would be protected by P2MR so nobody would care enough to activate EC disable”, then isn’t that a scenario where P2MR usage has successfully protected the network, and thus a good thing?
Could you clarify, what does P2MR incentivize beyond PQC access? The argument at the beginning of your post was about CISA.
Big bag holders have the technical understanding to use P2MR properly, and could even afford P2MR with pure PQC spending paths. They are also well-incentivized to do so, because quantum theft could destroy their business and the wealth of their customers/investors. ↩︎
: 
). Under these assumptions, why would you ever use the PQ spending path? That would make even today’s P2WSH “secure”. I don’t think that makes sense.
and 