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



Summary:

The author of a post on Bitcoin-dev discusses the potential uses of covenants in Bitcoin. They exclude vaulting from their enumeration of covenant uses, as they believe coin pools to be the most potentially valuable use for covenants. However, a workable design for coin pools has not yet been proposed, so the author focuses on vaults, which can be implemented in various ways and allow significant derisking of custody for Bitcoin users interested in holding their own coins. The author argues that CTV is a low-risk way of getting vaults and justifies its added validation complexity, which is modest compared to other covenant proposals. The author acknowledges that recursive covenants need a lot of work and suggests that throwing CTV to the wayside because it isn't a 100% solution to every possible covenant use would be like slamming the door on P2SH because Taproot might come along later. They believe that more general covenant abilities are desirable but may require years of work to develop. The author responds to another post by David A. Harding, who questions how the technical community will determine the best approach to covenants. The author argues that the best approach depends on demonstrated use cases and intent to use the change, alignment with Bitcoin's design and goals, developer and community response, and a well-reviewed and complete implementation. They also suggest starting simple and general, gathering real usage data, and then optimizing for demonstrated needs. Finally, the author addresses concerns about reverting to earlier consensus rules and gives future developers the option to drop no-longer-used consensus code as a practical simplification. They believe that giving developers the option to forget about those rules eliminates one of their concerns about making consensus changes without fully proven demand for that change.


Updated on: 2023-06-15T19:07:20.986502+00:00