CTV+CSFS: Can we reach consensus on a first step towards covenants?

The current discourse within the developer community regarding "covenants" or "contracting primitives" in Bitcoin has been highlighted as cyclical, with little convergence on their practical use-cases that would justify consensus changes to Bitcoin Script. This dialogue traces back to initiatives such as Jeremy's early 2022 effort to activate CTV (CheckTemplateVerify), alongside various efforts by individuals and groups like AJ Towns with bitcoin-inquisition, the Bitcoin Contracting Primitives Working Group on IRC, Optech, and initiatives like op.next to rejuvenate in-person Scaling Bitcoin discussions. These endeavors underscore a collective attempt to refine the development process for consensus changes but also reflect a stagnation in achieving major technical innovations, particularly in discovering new cryptographic primitives that enhance operational efficiency.

Most advancements have centered around opcode-level efficiency enhancements or innovative ideas like BitVM or ColliderScript. However, these innovations, while noteworthy, do not match the performance or expressivity of their theoretical counterparts at the consensus level. The discussion also touches upon the broader issue of achieving social consensus on specific use-cases that are technically and economically persuasive enough to warrant changes to Bitcoin Script. An undercurrent in this debate is the notion that without community consensus, the alternative path of forking Bitcoin Core to implement consensus changes introduces its own set of challenges. The concern here revolves around the long-term health and stability of the Bitcoin network, suggesting that such drastic measures may not be the most prudent course of action when considering consensus alterations.

The author expresses a conditional openness to minimal Script changes aimed at enhancing self-custody of Bitcoin coins, provided these do not introduce transaction-withholding risks or expand the attack surface for denial-of-service against full nodes. Any additional benefits from such changes that extend to other use-cases are viewed as ancillary. There is a call for developers within the community to articulate which use-cases they find compelling, along with any specific primitives they believe could facilitate these use-cases, or conversely, to outline the technical shortcomings or limitations that make certain primitives ill-suited to their needs. The emphasis is on fostering a constructive dialogue based on technical merits and concerns rather than relying on superficial indicators of approval or interest, such as social media likes or upvotes. The writer concludes with a readiness to accept the status quo if the discussion fails to progress, underlining a cautious approach to consensus changes within the Bitcoin protocol.