Hi all, In parallel to the threads[1][2][3] discussing the P2TRv2 and P2MR concepts, I'd like to talk about the possibility of codifying in the consensus rules the (expectation of) the disabling of EC opcodes/paths within the new output type.
The motivation for this is that while P2TRv2 has a "soft" built-in expectation of a future softfork that will disable EC opcodes/paths (just within the new output type itself) at the right time, its consensus rules are identical to P2TR (with the exception of PQC opcodes, if those aren't also added to P2TR). Plans and intent of protocol designers are one thing, but the future ecosystem isn't beholden to those: the only certainty is the adopted consensus rules themselves. Without confidence that the intended disabling will happen, it becomes unclear what CRQC-resistance the P2TRv2 type offers. Meanwhile, P2MR as formulated doesn't need/have such an expectation, but would still benefit from it, as users are otherwise restricted to (IMO) extremely onerous restrictions on public key sharing. To some extent, this is an unsolvable problem: we cannot codify plans that depend on outside-world conditions like CRQCs existing. Still, approximations exist which can be added as automatic triggers for this EC disabling, along with the new output type itself: * Tripwire (P2XX-T): use the presence of a NUMS point spend as trigger (suggested by Tadge Dryja[4]). Specifically, as part of the softfork definition, a NUMS point is picked. Whenever a transaction is mined whose input contains a successful "<NUMS> OP_CHECKSIG", EC opcodes/paths are disabled within the new output type, as of the next block. Note that the tripwire isn't intended as a replacement for the expected future EC-disabling softfork; instead, it puts an upper bound on that disabling. * Miner Lockdown (P2XX-ML): allow a hashrate majority/threshold to trigger the disabling, allowing a faster reaction time to urgent CRQC threats. Practically, this can be achieved by bundling the expected EC-disabling softfork with the softfork that introduces the new output type, but giving the disabling one a separate, and very long or infinite, activation window. This means that in addition to expecting the future ecosystem to decide when Q-day is too close, the hashrate majority is allowed to make that call too. (suggested offline by Sjors Provoost) * Combination (P2XX-T-ML): trigger EC disabling either through Tripwire, or through Miner Lockdown. I believe P2TR-T and P2MR-T are unambiguous improvements over P2TRv2 and P2MR respectively. This is because: * With Tripwire, anyone with a CRQC can, without permission, disable the EC paths/opcodes in the new output type for everyone. Because of that possibility, disabling is something all users of the new output type need to be prepared for at all times, and thus the later EC-disabling softfork cannot be considered confiscatory. That could otherwise be a reason to oppose the future EC-disabling softfork. Consider P2TR and P2TRv2. If there are no differences in consensus rules between them, it is worth asking why the future ecosystem should be expected to disable EC paths & opcodes in one but not the other, just based on earlier-stated plans. With Tripwire, disabling EC in P2TR-T is categorically non-confiscatory, making doing it there an objective choice. * Relatedly, for the same reason it likely convinces users and wallet developers to test, more seriously, the usability of the expected PQC paths, as not doing so inevitably means risking burning those coins. This is especially important for P2MR, which has some incentives to use it beyond CRQC-protecting coins. * The only downside I see is some additional technical complexity. The ability to sign with a NUMS point is an unequivocal proof that the secp256k1 ECDLP assumption no longer holds, and is thus a clear upper bound on when EC ought not to be used anymore. Note that this differs from a canary (an idea which has also been discussed) that uses a weaker curve, as the goal of those is to be predictive. The point here is specifically to just be an upper bound. To me, this makes both P2MR-T and P2TR-T more "Later"-style (as I've defined it in [5] and follow-ups) than P2MR and P2TRv2 respectively, which I consider an improvement for both. There still is an expectation of a later softfork that disables the EC paths/opcodes within the PQC output type, and thus the tripwire isn't actually expected to ever trigger. Still, I believe that its presence changes the game theory and incentives around usage of the output type, and future consensus changes. Of course, it cannot help with deciding what the right time for the EC-disabling softfork is, but it can help make it happen. The same is true for the Miner Lockdown idea. I'm a bit more hesitant about that, as it may be empowering the (collective of) miners too much. They always have the ability to just disallow EC spends of course, but the Miner Lockdown idea makes network nodes start enforcing the same rule too, making it irreversible. On the other hand, it is still opt-in (users deciding to move coins to the new output type), and this becomes them choosing to give miners a Lockdown button, which can presumably be used on shorter notice than the ecosystem can agree on a consensus change (even if it's pre-planned). I'd prefer to keep the discussion here just about adding the Tripwire and/or Miner Lockdown ideas, rather than MR vs TR, as I think this is orthogonal to the distinction between those. Thoughts? -- Pieter [1]: https://groups.google.com/g/bitcoindev/c/Qy4gwAGTK2w/m/_CjQ8xvdAAAJ [2]: https://groups.google.com/g/bitcoindev/c/p8AVEmAtWdA/m/T7UWqgnvAAAJ [3]: https://delvingbitcoin.org/t/public-key-recovery-for-ec-leaves-in-p2mr-bip-360/2603 [4]: https://groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/8nr6I5NIAwAJ [5]: https://groups.google.com/g/bitcoindev/c/p8AVEmAtWdA/m/Gona1fr3AgAJ -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/yHRpA2LEJ2AugT4W2KiWO3ggSims4GuHBkr6rWtE-e1uVC2wh3ZqD4bUDyxXq1iEuPrezhZZeqDoG7uBLNvjbW0sk_UTorI1Pkz6LcKhXRA%3D%40wuille.net.
