Where I stand on Bitcoin covenants and my support for each of them.
Before examining specific covenant proposals, I want to clarify my overall covenant stance: The window for a user-activated soft fork (UASF) is narrowing and as such I strongly support covenant upgrades that enhance trustless settlement and reduce liveness requirements, provided they are thoroughly vetted and technically sound.
My support is not based on immediate user demand for these features, but on the capabilities they enable. I said what I said, the functionality has to be there. There happens to be a yearning for unilateral exits and reduced liveness, but even if there wasn't, I would still consider these features a 'must have' for self-sovereign money.
Onwards.
Hard to oppose it, it really does do everything, even if it is inefficient and costly. I do worry what the bitcoin blockchain mempool will look like with everyone trying to deploy their own SNARK verifier onchain, and fraud proofs being constantly checked, but it is ultimately a free market and I would be hypocrite to try and constrain how people chose to use bitcoin. It also happens to enable transaction introspection, with OP_CSFS. I personally think that OP codes should stand on their own but I would be remiss not to mention the above as one of the favourite things that OP_CAT enables.
Sasily the king of the hill, being able to check for singing of specific data to prevent spending really knocks it out of the park, I thinks this is easily the most supported op code addition and frankly my favourite one.
The next on my list of wants, extremely simple and battle tested, should've been soft-forked into bitcoin ages ago. The main criticism, that I sort of stand behind of, is that it doesn't do enough. And as a standalone op code it is insufficient. Wheels as stand alone inventions aren't very useful either but in combination with other elements it is extremely useful, sometimes you just have to introduce table stakes. In this case I think OP_CTV simplicity and limited functionality is a feature not a bug.
This is OP_CAT with extra steps, so Im going to go with no. Just use cat. I understand wanting this if you're afraid of recursion and introspection. I am not.
I do not like it, at all. I think vaults are a problem and im surprised more people don't strongly oppose it. In an adversarial situation, where a user is kidnapped or wrenched attacked, IN MY OPINION, it increases the length of the situation so the attacker can ensure he has control over the funds and is not being duped. People that want to steal from you will not be deterred by complexity. net negative.
Have always been a huge fan of MATT, it is the way. I find it clean elegant and useful, I realise vaults can be enabled and this seems to be the reason most people want it, but it also enables other constructions like token protocols with advanced rules, which I believe will gather a LOT of adoption when pushed through.
OP_TXHASH: evaluatingOP_APO: evaluatingOP_INTERNALKEY: evaluating
All in all my dream team would be: CTV+CSFS+CAT+CVV
INTERNAL_KEY would be a nice addition but one I can live without.
VAULT and PAIR_COMMIT are strong NOs for me.