So in my view, of someone who has been involved or have followed the conversation on "covenants” / “contracting primitives” on the last 3 / 4 years, we’re more or less doing circles as there is not real convergence on the use-case worthiness, that are improved by covenants.
Following Jeremy’s 1st initiative to activate CTV in early 2022, there have been people for who have take a step back and try to improve the development process of consensus changes, be it AJ Towns with bitcoin-inquisition, myself with the Bitcoin Contracting Primitives WG on IRC, Optech with a collection of all covenant ideas, some people who have attempted to reboot in-person Scaling Bitcoin with op.next, etc.
From the last 3 / 4 years, I don’t think there have been major technical breakthrough on the conceptual side (i.e finding new cryptographic primitives that allows to do more with less), and all the conceptual advances have been either lines on opcode-level efficiency tricks or ideas like BitVM or ColliderScript. Those latest novels ideas are interesting in themselves, though of course, there are not achieving the same in terms of performance or expressivity than their logical equivalent, at the consensus-level.
So I think, we’re still halting on the lack of social consensus on specific use-cases, that are strong technical and economical motivation enough to warrant consensus changes of Bitcoin Script.
If there is an inability as a community to come to consensus, there is always the path to fork bitcoin core and do an activation client. While I strongly believe more competing clients in the bitcoin space is a good thing on the long-term (yes - you can outcompete bitcoin core on so many technical dimensions), I don’t believe this is the way to go when we’re talking about consensus changes. There is a value in itself in the stability of the bitcoin network, which is not worth to play on a coin toss, or bargain with brinksmanship.
My position, as expressed in the last paragraph of my previous post, is that I can be supportive of a minimal Script change improving bitcoin coins self-custody, at the condition it doesn’t introduce tx-withholding risks or extend the DoS surface of full-nodes. If it has a side-effect to improve other use-cases, cool, but not something which is ranking high in my list of bitcoin technical items I’m interested to contribute on.
In a spirit to move the conversation forward, we had 11 developers expressing on this thread so far, eventually each one could express which use-cases they can be interested by, and if there is any primitive they think will improve the use-case, or the technical reasons they think a primitive have weakness, limitation, is not suiting their particular use-case, etc.
Expressing technical motivations why you’re against an idea (e.g me against CSFS due to tx-withholding risk), is I think a good development practice as objective elements can be discussed on, rather than information-poor marks like “thumbs up” or “like” on gh or twitter.
If the conservation stalls, I’m fine with the status quo.