It appears to me that there are various ways to build covenants and vaults with opcodes and sighash flags that are not yet enabled in Bitcoin (e.g. OP_CHECKTEMPLATEVERIFY, SIGHASH_ANYPREVOUT, OP_CAT).

Assuming these are considered for the next soft fork in Bitcoin what downsides are there to just enabling all of them and seeing what people build with them?

Obviously taking up a reserved OP_NOP with a potentially suboptimal opcode is one downside. And in the worst case a botched opcode could mean that a UTXO might not be able to spent (or impose unacceptable verification costs on full nodes). Are there any other potential downsides?

I suppose this is partly answered by what motivated Satoshi to disable a lot of opcodes in 2010 which I'm not clear on. The motivation appears to be security but again I'm not clear on what exact attacks that were possible with what opcodes and the severity of those attacks.

It appears to me that there are various ways to build covenants and vaults with opcodes and sighash flags that are not yet enabled in Bitcoin (e.g. OP_CHECKTEMPLATEVERIFY, SIGHASH_ANYPREVOUT, OP_CAT).

Assuming these are considered for the next soft fork in Bitcoin what downsides are there to just enabling all of them and seeing what people build with them?

Obviously taking up a reserved OP_SUCCESSx with a potentially suboptimal opcode is one downside. And in the worst case a botched opcode could mean that a UTXO might not be able to spent (or impose unacceptable verification costs on full nodes). Are there any other potential downsides?

I suppose this is partly answered by what motivated Satoshi to disable a lot of opcodes in 2010 which I'm not clear on. The motivation appears to be security but again I'm not clear on what exact attacks were possible with what opcodes and the severity of those attacks.

It appears to me that there are various ways to build covenants and vaults with opcodes and sighash flags that are not yet enabled in Bitcoin (e.g. OP_CHECKTEMPLATEVERIFY, SIGHASH_ANYPREVOUT, OP_CAT).

Assuming these are considered for the next soft fork in Bitcoin (not a certainty) what downsides are there to just enabling all of them and seeing what people build with them?

Obviously taking up a reserved OP_NOP with a potentially suboptimal opcode is one downside. And in the worst case a botched opcode could mean that a UTXO might not be able to spent (or impose unacceptable verification costs on full nodes). Are there any other potential downsides?

I suppose this is partly answered by what motivated Satoshi to disable a lot of opcodes in 2010 which I'm not clear on. The motivation appears to be security but again I'm not clear on what exact attacks that were possible with what opcodes and the severity of those attacks.

It appears to me that there are various ways to build covenants and vaults with opcodes and sighash flags that are not yet enabled in Bitcoin (e.g. OP_CHECKTEMPLATEVERIFY, SIGHASH_ANYPREVOUT, OP_CAT).

Assuming these are considered for the next soft fork in Bitcoin what downsides are there to just enabling all of them and seeing what people build with them?

Obviously taking up a reserved OP_NOP with a potentially suboptimal opcode is one downside. And in the worst case a botched opcode could mean that a UTXO might not be able to spent (or impose unacceptable verification costs on full nodes). Are there any other potential downsides?

I suppose this is partly answered by what motivated Satoshi to disable a lot of opcodes in 2010 which I'm not clear on. The motivation appears to be security but again I'm not clear on what exact attacks that were possible with what opcodes and the severity of those attacks.