I support this effort, as reflected in my pinned post on X.
To slightly expand on why specifically CTV+CSFS(and IKEY+PC?):
IKEY: INTERNALKEY PC: PAIRCOMMIT
There’s a tension between “only change bitcoin consensus in gravest extremity” and “upgrade bitcoin whenever there’s a clear improvement to be had”. Team Slow and Steady (as promoted by @ajtowns, @moneyball, and others) is a proposed middle of the road that aligns well with the CTV+CSFS upgrade.
While there are many, @AntoineP included, who are in a fourth camp of “only change bitcoin consensus when there is a strong and clear reason”, that standard is simply not realizable while navigating the delicately balanced space between “only in gravest extremity” and “slow and steady”. Any upgrade that would add sufficient capabilities to show such a strong and clear reason will necessarily also raise the specter of potentially weakening the incentives which are necessary for bitcoin’s continued success. While I personally am confident that an upgrade such as CAT, Simplicity, or Lisp would not harm the incentive structure, that is difficult (I think impossible) to defend to Team Slow and Steady.
Therefore, we are left not with a choice of “CTV+CSFS now or something with stronger justification later” but rather “CTV+CSFS at some point, or nothing until solving the 2106 timestamp overflow”.
Lastly, I’d like to expand on why I think CTV+CSFS alone may need IKEY and PC to reach activation.
There was some debate during the development over the exclusion of a keyless spend. This was resolved with the justification that nearly all protocols have a cooperative n-of-n case that will dominate over whatever uncooperative cases. While this is broadly true, for some of these protocols, success would mean that the cooperative case itself is rarely broadcast which would then imply that uncooperative cases are the main spend seen in blocks. For those protocols, IKEY largely mitigates the cost of the mandatory key spend. Without IKEY, those potentially dominant spends are 32WU larger for no reason.
Thanks to @JeremyRubin’s key laddering concept, we know that CSFS alone enables Merkle-tree-ish commitments by using sigops to ladder keys which then commit to items. Given this, and the usefulness of such multi-commitments, I think it would be poor stewardship to add CSFS to bitcoin without also enabling multi-commitments directly. If we do so then protocol developers will use sigops instead, pushing up validation costs (not above current worst cases but simply unnecessarily). When I was developing the CSFS BIP, I briefly explored the idea of using magic keys of small sizes to specify additional items from the stack to sign over. In the end, I concluded that that functionality belongs in a separate opcode. @moonsettler developed PC as that opcode.
To tie this all together: While CAT would also enable multi-commitments for CSFS, CAT also violates the “slow and steady” ethos by introducing many capabilities with difficult to reason about incentive implications. PC is ideally situated to be everything we need to maintain incentive alignment between nodes and application protocol developers in a post-CSFS world, without introducing additional capabilities beyond those already added by CSFS itself.