My comments on the proposed opcodes in the "Covenants support" page:
Gist
Opcodes Zoo
Opcodes Zoo. GitHub Gist: instantly share code, notes, and snippets.
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
