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 to be impossible for most users. 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.
Telling people they’re safer by using P2MR “correctly”, without recognizing that “correctly” is a practical impossibility to them, 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.
You’re suggesting an output type that automatically becomes insecure, some years in the future? We may be forced to do so by CRQC evolution that ultimately boils down to the same thing, but building it in seems like an extremely controversial take to me. I don’t think this is worth it at all.
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.
: 
). 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.