Automatically reverting ("transitory") soft forks, e.g. for CTV



Summary:

The discussion in this email thread revolves around the implementation of covenants in Bitcoin. The author argues that while there may be alternative proposals to CTV, they have not been developed as extensively and therefore should not be seen as a lack of interest in covenants overall. Rather, it is reasonable to assume that those interested in covenants have primarily focused their attention on CTV. The author also argues that it shouldn't be necessary for multiple competing proposals to be fully tested before integrating one of them into Bitcoin. Instead, if consensus can be reached on moving forward with one proposal, and concrete commitments are made to develop alternatives over the next few months, it would be worth waiting for. However, in the absence of such consensus and commitments, the author suggests that CTV should not be set aside in favor of an unlikely hypothetical. The email thread also discusses the difficulty in choosing the "best" covenant design, as different designs optimize for different things, and implementing more than one design would require data on usage and fees. Finally, the safety concerns related to a CTV soft fork could be mitigated through code review and community support, but there are still risks associated with doing a fork that come from the process and nature of forks themselves, which cannot be avoided through careful analysis or testing.


Updated on: 2023-06-15T19:09:04.728077+00:00