heh -- I pointed out these evil multisig covenants in 2015 :) https://medium.com/@jeremyrubin/regulating-bitcoin-by-mining-the-regulator-miner-attack-c8fd51185b78 I'm relatively unconcerned by it except to the extent that mining centralizes to the point of censoring other traffic.

Overall, I think this is a great conversation to be having.

However, I want to push back on David's claim that  "Respecting the concerns of others doesn't require lobotomizing useful tools.".

CHECKSIGFROMSTACK is a primitive and the opcode is not being nerfed in any way shape or form. The argument here is that doing CSFS and not CAT is nerfing CSFS... but CSFS is an independently useful and cool opcode that has many of it's own merits.

Further, as described in my [blog post](https://rubin.io/blog/2021/07/02/covenants/), CSFS has very high "design specificity"... that is there's not *that* many design choices that could possibly go into it. It's checking a signature. From the stack. That's all folks! There are no design compromises in it. No lobotomy.

OP_CAT is more or less completely unrelated to CSFS. As Andrew has [demonstrated](https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html), *just* OP_CAT alone (no CSFS) gives you covenants (albeit in a hacky way) with Schnorr.

I think roconnor agrees that CAT(+CSFS?) are not really a "fantastic" way to do covenants, that there are more direct approaches that will be better or neccessary such as TWEAK or UPDATETAPLEAF. Let's work on those! But let's also not hold up progress on other useful things while those are brewing.

Non-Redundancy should be a non-goal for script -- although we strive to be minimal, redundancy is inevitable. For example, OP_SWAP has identical semantics to <1> ROLL, but SWAP is a common enough use that it is pragmatic to assign it an opcode and OP_ROLL does something distinctly enhanced. Similarly, even if we add CAT we will surely come up with saner ways to implement covenant logic than Andrew's Schnorr tricks.

CTV in particular is designed to be a part of that story -- enough functionality w/o OP_CAT to work *today* and serve a purpose long into the future, but with OP_CAT (or shastream preferably) enhances it's functionality in a useful way and with introspection opcodes (perhaps like those being developed by elements) further gains functionality. Perhaps the functionality available today will be redundant with a future way of doing things, but we can only see so far into the future. However, we can see that there are good things to build with it today.

In the future when we have specific use cases in mind that *aren't* served well (either efficiently or at all) by the existing primitives, it's completely acceptable to add something new even if it makes an existing feature redundant. APO, for example, will be redundant (afaict) will Glen Willen's [Bitmask SigHash Flags](https://bc-2.jp/archive/season2/materials/0203_NewElementsFeaturesEn.pdf) should we ever get those.