What's a good stopping point? Making the case for the capabilities enabled by CTV+CSFS

In a recent exchange on the Bitcoin Development Mailing List, the discussion centered on the potential for introducing new opcodes to Bitcoin's scripting language aimed at reducing interactivity within second-layer protocols. The conversation acknowledged that previous attempts to introduce such capabilities often overpromised their utility, particularly in relation to vaults, which are not considered a viable use case for these new opcodes. The dialogue emphasized the importance of focusing on what these enhancements genuinely offer—specifically, the ability to reduce interactivity—rather than being swayed by misleading or overly ambitious claims about their functionality.

The debate also touched upon the broader implications of such updates to Bitcoin's script. There was an acknowledgment of the danger in supporting proposals based on the allure of future possibilities, like vaults, without a clear and present need. This perspective is driven by a cautious approach to development, prioritizing clear, demonstrable benefits over speculative advantages. The conversation further explored the concept of modularity and forward compatibility, suggesting that while flexibility in anticipating future upgrades is valuable, it must be weighed against the risks and complexities introduced by such an approach.

A specific point of contention revolved around whether the proposed enhancements should stop at programmable introspection or include more advanced features like programmable forwarding of values and conditions, and even Commitment to Transactions (CTV). The potential for a comprehensive overhaul of Bitcoin Script, including the introduction of a significantly different scripting language like BTCLisp, was debated as an alternative to incrementally adding new opcodes.

Furthermore, the discussion acknowledged that while future extensions might provide greater expressivity, the simplicity of certain capabilities—such as committing to the next transaction and verifying signatures for arbitrary messages—should not be dismissed. These simpler capabilities could be implemented with minimal deviation from existing mechanisms, thereby limiting the introduction of technical debt. This contrasts with the potentially larger technical debt and complexity associated with more involved capabilities like arbitrary transaction introspection.

In summary, the discourse among Bitcoin developers reflects a careful consideration of the balance between innovation and stability, emphasizing the need for clear, practical use cases for any proposed changes to the protocol. The conversation underscores a preference for a cautious, deliberate approach to development, favoring enhancements that offer tangible benefits without compromising Bitcoin’s foundational principles.