On Tue, Jul 6, 2021 at 2:26 AM Billy Tetrud <billy.tetrud@gmail.com> wrote:

> when people are talking about enabling covenants, we are talking about whether OP_CAT should be allowed or not

Are they? Are you implying that anything that enables covenants is equivalent to enabling OP_CAT? Generally when I think about enabling covenants, I'm thinking more about OP_CTV (or some similarly specific opcode).

> OP_TWEAK

I wasn't able to find anything about what that is. Would you mind clarifying what that concept is?

In tapscript one can generally recover the current input's scriptPubkey through sighash introspection via the usual covenant tricks. This allows you to make a recursive covenant by spending funds back to the same identical scriptPubkey. However, in order for a recursive covenant to be actually interesting, there needs to be some sort of state update in each transition. If there is no state update then sending funds back to itself is of very limited value. It will reset the timer on relative locks, but that is about all.

The "normal" way of writing useful recursive covenants is to modify the scriptPubkey by changing a fragment of it that contains some sort of state. However in order to update a tapscript pubkey one needs to apply not only hashing, to create a Merkel root, but also to create a tweaked taproot pubkey that commits to this root. While script currently comes with a SHA-256 hashing opcode, there is no opcode that will let you perform the necessary tweaking to create a taproot scriptPubkey.

But as I mentioned afterwards, there are other places in the UTXO that you could put data in order to perform a state update.