salvatoshi on Nostr: My comments on the proposed opcodes in the "Covenants support" page: I think it's not ...

My comments on the proposed opcodes in the "Covenants support" page:

https://gist.github.com/bigspider/2b0892da45884d26eb7f4c9cb2395a7d

I think it's not very meaningful to "support" specific opcodes: most opcodes are not very good in isolation, but might be good in the right combination.
A soft-fork can enable multiple opcodes, and it should be a coherent set of changes that does one or a few things well.

Therefore, I think it's more important to identify and discuss the "primitives" that the opcodes (and packages of opcodes) can enable.

I identify the following tentative list of primitives enabled (one way or another) by the various proposals:

- commitments to transactions
- signing a message
- vector commitments
- concatenation
- state-carrying UTXOs
- multi-step transactions
- generic introspection

I argue that if some opcodes poorly enable a valuable primitive, then other opcodes that implement that primitive _well_ should be enabled together.
Otherwise, we're shooting ourselves in the foot with the bloat that will inevitably come.

I discuss my opinion on whether or not it might be dangerous to enable new primitives in Script.

Finally, I suggest a potential minimal package of opcodes that would enable _all_ the identified primitives pretty well, while each is fairly simple and self-contained:

- OP_CTV
- OP_CAT
- OP_CCV
- OP_CSFS
- OP_AMOUNT