Next I’ll give my own (current) view. It is an opinion, and I would like to convince others of its merits, but is by no means a NACK of alternative options.
I believe the best solution is a combination of P2TRv2 and P2MR, covering distinct use cases.
-
To make “emergency” PQC available to as many users as possible: a P2TRv2 output type, with Tripwire and Miner Lockdown, and with a hash-based PQC signature opcode.
- The primary design goal is maximizing ease/incentives for adoption: every user/coin that adopts it, is one that is no longer subject to the steal-or-freeze dilemma. I consider that dilemma an severe threat to Bitcoin (a more urgent one than CRQCs themselves even), because both options involve giving up a fundamental value proposition Bitcoin has. Still, all coins that move to PQC-enabled outputs beforehand are taken out of the equation, and that long tail is something near-future development can have an impact on. Thus, I believe maximizing those ought to be our #1 priority. To that end:
- P2TRv2 preserves the same fee profile as P2TR, avoiding “not migrating because it costs more”, and does not lose the P2TR incentives that brings. This also minimizes negative impacts on Bitcoin prior to Q-day.
- For developers/infrastructure, it is maximally close to today’s world, avoids the complexity of adding a new witness style or a new ECC signature scheme.
- It is compatible with most/all workflows I’m familiar with, including xpub/descriptor sharing (it would mean a static/short list of PQC keys in the descriptor, which isn’t great for privacy, but much better than users not being able to adopt PQC at all).
- I’m ambivalent about making the PQC opcode hybrid. Stateful signature schemes are scary, and only permitting them to be used in conjunctions with ECC would give me more confidence about not losing security due to incorrect usage. It however also adds complexity for adoption, and as mostly an emergency mechanism, users may opt for the safer stateless signature schemes anyway.
- No P2MR or P2TRH. These add additional complexity, cost, or both, to users that may stifle adoption, and I believe the additional security to be had from the ability to not expose EC points on chain before ECC spending requires careful and uncommon workflows from users anyway (no key reuse, no xpub/descriptor sharing, very different hardware wallet designs, …). Those who are willing to adopt those clearly do not need “ease of adoption”, can thus use P2MR (see below) instead.
- The primary goal is having something available that can be adopted quickly. The actual automatic ECC-disabling mechanisms (especially Miner Lockdown) that may be more bikeshed-prone could be introduced later when/if CRQC threats are closer.
- The primary design goal is maximizing ease/incentives for adoption: every user/coin that adopts it, is one that is no longer subject to the steal-or-freeze dilemma. I consider that dilemma an severe threat to Bitcoin (a more urgent one than CRQCs themselves even), because both options involve giving up a fundamental value proposition Bitcoin has. Still, all coins that move to PQC-enabled outputs beforehand are taken out of the equation, and that long tail is something near-future development can have an impact on. Thus, I believe maximizing those ought to be our #1 priority. To that end:
-
To prepare for longer-term full migration, a P2MR-based output type, with Tripwire and Miner Lockdown as well, plus a new witness style to give its ECC usage the same fee structure as P2TR. It comes with hash-based PQC opcodes as well, and post EC disabling, newly discounted versions of those can be added.
- The primary design goal is putting the pieces in place for a longer-term migration plan, even if the actual cryptographic schemes to make that realistic don’t exist yet, are too slow/large, or have too low long-term confidence in their security. To that end:
- No more P2TR variants, to avoid the overhead/complexity of a privileged ECC-only path which is useless in a post-ECC world.
- Starts by adding infrastructure for new witness styles, even though that adds complexity, because a full migration post-CRQC will need those anyway. This likely complicates rollout and adoption, but that is fine; this is mostly intended for usage after Q-day.
- Urgency is not as important here, and this can be deployed on a longer timescale than the P2TRv2 output type above. The use of a new witness style may need a lengthy upgrade anyway, because it needs a transaction serialization / P2P change to rely new witness data.
- This can also functions as a fallback option for users to send theirs coins to post-CRQC if somehow ECC disabling does not happen in time, or users who want to safeguard their coins for that eventuality. I think the benefits of that option are limited, but recognize there is demand for it.
- Depending on which PQC scheme is added here, and CRQC sentiment at the time, hybridization may be more important here, as there is less downside to its complexity and size, and this is intended for longer-term migration.
- Use of PKR is possible here, but given that PKR verification is (slightly) slower than normal ECC verification, I don’t think it’s unreasonable to just use normal BIP-340 for ECC instead, and use a costing/discount model that compensates for it.
- The primary design goal is putting the pieces in place for a longer-term migration plan, even if the actual cryptographic schemes to make that realistic don’t exist yet, are too slow/large, or have too low long-term confidence in their security. To that end:
Regarding “relying on EC disabling”
Let’s zoom out for a bit. All continued use of ECC in the face of rising CRQC probability relies on some entities making the call as to when ECC is to be considered vulnerable, and none of them have perfect visibility into whether a CRQC might exist. The differences between the various schemes are just in which entities those are:
- Any scheme implicitly allows the future Bitcoin ecosystem to make that call, through an ECC-disabling consensus change.
- With Tripwire, any cooperative CRQC can make that call.
- With Miner Lockdown, the hashrate majority can make that call.
- With P2MR and P2TRH, the owners of the coins can make that call too, under certain conditions.
The EC-disabling timing problem, as you call it, is the P2TRv2-specific lack of (4), I believe? That is undeniably a difference, but I think it is easy to overstate its importance, as in practice many if not most users of other other output types will equally rely on (1)-(3). Many casual users are likely not paying close enough attention, and will defer to others regardless. Any user that shared public keys/xpubs/descriptors to untrusted parties or reused addresses, gave up their ability to make that call, possibly in ways beyond their control (how can they stop being paid to the same address twice?), or even unknowingly.
So seen in perspective, P2TRv2 is effectively offering users the ability to opt out of making that call themselves. Given that many likely weren’t going to exercise that anyway, and it comes with reduced cost, simplicity, and/or impact on the ecosystem, possibly increasing adoption before Q-day, I think that is a win. And once P2MR is available too, (4) remains an option for those actually willing and able to take advantage of it.
I’m not disagreeing that this results in a tenuous position of needing to rely on timely ECC-disabling, but I don’t think it is unique to P2TRv2. It is the price we pay for wanting to continue to use ECC for as long as possible.
I don’t think things are that black & white.
If you want a “cryptographic” level of confidence, the only option is P2QR (or even disabling ECC entirely). Anything else, e.g. P2MR, involves some hope that one of (1)-(4) above can act in time before a CRQC emerges. We don’t do just P2QR, because of a (very reasonable) trade-off between adoption and security: P2QR would only be adopted by a tiny minority, so we accept (1)-(4) in addition to purely cryptographic assumptons, in exchange for (likely) far more coins being able to move to PQC outputs in the first place. Those who do not want to rely on (1)-(4) have the option of using P2MR in a PQC-only fashion.
Going from P2MR to P2TRv2 is a (IMO small) further step in the same direction: it accepts just (1)-(3) is enough, in exchange for getting an output type that is possibly more easily adopted, cheaper, with less impact on Bitcoin before Q-day. Those who do not want to rely on (1)-(3) alone and want (4) have the option of using P2MR still if both are available.
You can argue that that step is a step too far, and that this trade-off is not worth it. I would disagree with that, but it is a defensible position. Dismissing it as “not cryptography” is not a constructive stance, however.
Regarding “Timing Q-day accurately”
A common theme I see being brought up in predicting Q-day is that we shouldn’t expect a nice progressing of milestones being broken along the way, quipped by Scott Aaronson as:
asking “so when are you going to factor 35 with Shor’s algorithm?” becomes sort of like asking the Manhattan Project physicists in 1943, “so when are you going to produce at least a small nuclear explosion?”
I accept that view, and the conclusion that one shouldn’t wait to deploy PQC until there are measurable milestones. That is, we should be working now towards providing PQC output types in Bitcoin. But that is what we’re doing, I think, and this discussion is part of that.
But I also think it’s good to not take this too far; I expect there will still be milestones, they will likely just happen at a compressed pace, shortly before CRQCs become feasible. The fact that we shouldn’t wait to deploy PQCs isn’t the same as saying we shouldn’t wait to disable ECC. Even a few weeks notice may be enough with Miner Lockdown. If it’s something that’s clearly close to CRQC-levels, I can see that happening without much drama (note, again, I’m just talking about ECC disabling within the PQC output type(s), not general freezing).
This is an optimistic scenario. I obviously cannot promise that this is how things will go. If CRQCs happen entirely unexpectedly, and come into non-cooperative/malicious hands, we inevitably have a problem. However, I think there is little we can do today (besides providing a PQC output type) that improves the outcome in that situation: there will be chaos, forks with emergency general freezes, and various techniques implemented for recovery of old coins. Since it’s likely an undermining of Bitcoin’s value proposition anyway (“altcoin bootstrapped with Bitcoin’s UTXO set”), I see little reason why recovery techniques couldn’t be hardforked in even.
On the other hand, preparing for outcomes where ECC disabling can be timed correctly is something we can do today, so that is where I think our focus should lie.