Published on: 2022-04-25T05:12:10+00:00
In an email thread discussing the implementation of new features or opcodes in Bitcoin SCRIPT, a proposal is made to use real-world funds to prove demand. This involves using Smart Contracts Unchained and creating a mapping from Bitcoin SCRIPT opcodes to micro-opcodes. While this approach demonstrates real demand, there are concerns about security erosion and reliance on a federation. The possibility of reverting activated soft forks is discussed, but it is suggested that reverting without disrupting the network may not be possible. Concerns about specific covenant designs being discussed without actual implementations or sample usages are raised, with a suggestion to address this issue in the short-term. The focus of the discussion shifts to the implementation of covenants in Bitcoin, with arguments for and against CTV as the preferred design. The difficulty in choosing the "best" covenant design is acknowledged, along with the challenges and risks associated with doing a fork in Bitcoin. The lack of serious proposals other than CTV is noted, highlighting its simplicity and positive reviews. The potential uses of covenants, particularly vaults, are discussed, with CTV seen as a low-risk way to implement them. However, there is recognition of the need for more general covenant abilities and the time and effort required for their development. The practicality and utility of various covenant proposals are debated, with a preference for CTV due to its low-risk approach to vaulting. The criteria for adding a covenant to Bitcoin are outlined, including demonstrated use cases, alignment with Bitcoin's design, technical feasibility, and a well-reviewed implementation. The possibility of reverting to earlier consensus rules is also mentioned. The ongoing discussion about covenant designs is highlighted, with a lack of serious proposals other than CTV. The challenges of finding a preferable alternative and the need for complete specifications and tooling are discussed. Concerns about the long-term nature of CTV's use cases and its compatibility with a sunset period are raised. The suggestion is made to use CTV for most of the deployment to demonstrate real-world usage and convince others to make it permanent. Bitcoin developers discuss the best way to implement covenant functionality in Bitcoin, with no clear consensus on the best design. More data about user demand and usage is deemed necessary. The proposal of a transitory soft fork to activate different covenant designs is met with concerns about safety risks and recursion. Criticisms of CTV are discussed, including concerns about usage, maintenance burden, and the lack of consensus around concrete proposals for covenants. The need for real usage data and optimizing for demonstrated needs is emphasized. The risk and cost of doing a fork and the suggestion of adding "technical community consensus" as a factor in the process are also mentioned. The viability of the proposed BIP119 CTV is debated, with considerations of usage, maintenance burden, and consensus within the technical community. The importance of maintaining Bitcoin's culture of security and careful design is stressed. The possibility of modifying the witness discount in SegWit transactions through an additional soft fork is suggested, but concerns about potential confiscation of funds are raised. The variant of Speedy Trial being used and accusations of efforts to sabotage parallel UASF initiatives are also discussed. The importance of advocacy and improving logic is emphasized. The question of whether changes made by already activated soft forks can be reverted is raised, with suggestions for potential solutions. Concerns about increased weight making transactions invalid and criticism of the variant of Speedy Trial being used are expressed. The idea of making CTV an automatically reverting consensus change with an option to renew after five years is proposed. This allows experimentation with new features without permanent commitment. However, concerns about usage, maintenance burden, and the risk of losing money and potential miner censorship near the reversion date are raised. Alternative ways to activate CTV, such as a UASF client compatible with a speedy trial release, are suggested. The importance of allowing users to decide and preventing miner veto power is emphasized. Despite the downsides, an automatically reverting soft fork provides the opportunity to experiment with new features.The Bitcoin community expresses concerns about the future use of CTV due to maintenance and security issues. The proposal to automatically revert CTV as a consensus change after five years is discussed, allowing for experimentation without permanent commitment. However, there are potential risks such as the loss of funds and potential miner censorship. Further discussions on CTV are anticipated. A proposal is made to address criticisms against CTV by making it an automatically reverting consensus change with an option to renew, allowing for experimentation without permanent commitment. However, concerns about risks and potential miner censorship remain. Further discussions on CTV are expected.
Updated on: 2023-08-02T06:10:30.933585+00:00