APO does implement the most exciting application of CSFS + TEMPLATEHASH, that is, rebindable signatures, and in a cheaper way.
However, there are other applications of these opcodes that it doesn’t implement, like the cut of interactivety in certain protocols that depend on musig (e.g. ark), delegation, DLCs, etc. Even more, these opcodes could turn into flexible building blocks for other applications, specially after future softforks.
The problem isn’t necessarily that “enable too much”, but rather “creates many attack vectors and/or could cause practices we don’t want to enforce”.
E.g., CAT + CSFS + CTV could technically create a quasi-universal covenant construct, but in a rather ugly way, puttting the entire tx on the witness. This not only consume an unecessary big amount of block space, but also we are not so sure, as current technical consensus, if too powerfull covenants could create unforeseen attack vectors. In recent times we found new vectors and use cases that has been possible in BTC for YEARS (replacement cycle attack, bithash, etc., also, Linus found an unusual way to use CTV to commit for a pair input that has been unforeseen in the BIP for years), and have been unknown for the majority of its life. Now, imagine an update with uncountable ways to use and combine, we may easily find an attack vector years after activation.
CTV + CSFS (or TEMPLATEHASH + CSFS), however, are rather simple and predictable opcodes, and the community judges them to be safe.
Thanks for confirming my understanding. There’s some nice intuition here that isn’t present in the BIP-448 text. I’d like to open a PR to add it under Rationale, wdyt?
And risk surface worries is a given for every softfork BIP, not special to covenants BIP. When you read a softfork BIP, risk surface must be something you are thinking of. CAT is a rather different opcode, even though it implements similar use cases, it may seem kinda awkward to point it in this BIP.
user1 · 
cmp_ancp · 