CTV + CSFS: a letter

The discussion revolves around the challenges and perspectives associated with introducing feature soft forks within the Bitcoin Core project. A significant observation highlighted is that the enthusiasm for these soft forks primarily comes from individuals outside the current Bitcoin Core development team. Former contributors like James and Jeremy, alongside others, have shown interest but are no longer actively involved in Bitcoin Core's development. There's a suggestion to potentially attract more contributors who are interested in these changes by offering grants, acknowledging the steep learning curve and the daunting task of keeping up with ongoing developments. The email emphasizes the difficulty of integrating new proposals due to the extensive time required to onboard new developers and the possibility of shifting priorities as they become more involved.

Grants could serve as a motivation for new developers to contribute to soft forks, but there's a caution against creating incentives that might push developers to prioritize activation over thoughtful development, referencing past instances where such pressures led to developer burnout. The message reflects on personal motivations and specific features like vaults, which are deemed significant enough to warrant attention. There's an acknowledgment of the focus on Stratum v2 readiness as a current priority, overshadowing the immediate need for other proposed features such as congestion control or alternative Layer 2 systems. The email also mentions a reconsideration of the CheckTemplateVerify (CTV) proposal due to its potential to enable more user-friendly vault mechanisms than previously assumed.

Furthermore, the conversation touches upon the importance of privacy enhancements and expresses a preference for a more comprehensive soft fork proposal that addresses this alongside other issues. However, there's openness to exploring the proposed CTV + CSFS (CheckSigFromStack) combination without outright opposition, provided it doesn't introduce significant risks. The email explicitly opposes the idea of a Python-based alternative implementation for activating these changes, suggesting a level of scrutiny and caution towards how these developments should be approached and implemented.

In summary, the email encapsulates a nuanced view on the evolution of Bitcoin Core, highlighting the complexities of incorporating new features through soft forks, the potential role of grants in fostering contributions, personal priorities within the development landscape, and the careful consideration required when integrating significant changes to ensure they align with the broader goals and stability of the platform.