Author: Michael Folkson 2022-01-28 13:14:07
Published on: 2022-01-28T13:14:07+00:00
The Bitcoin community is currently discussing the implementation of a covenant opcode or sighash flag that would provide users with a vault strategy without requiring presigning transactions with ephemeral keys or multisig configurations. However, some stakeholders have pointed out that the ecosystem is still in its early stages and not widely using all available tools, such as Taproot trees and Miniscript. While there are proposals for new opcodes like TXHASH, it will take time to develop, test, and release them.Developers are currently working on getting Miniscript finalized and supporting basic send and receive to P2TR addresses. There are also covenant opcodes enabled on Liquid that could be used for vault prototypes. The conversation about the pros and cons of various proposals and testing protocols on signets and sidechains is productive. But when it comes to urgency or activation speculation, some developers are perplexed, suggesting that this viewpoint ignores where the ecosystem currently stands with tooling and vault prototypes.The debate over covenant opcodes involves technical debt and soft fork processes, which can be risky. While some stakeholders advocate for implementing CTV, others suggest that TXHASH+CSFSV would yield more value and allow for oracle signature verification. However, concerns have been raised about the complexity and combinatorial growth of flags, necessitating comprehensive tests and understanding of the behaviors they expose. Additionally, flexible hashing has the potential for quadratic hashing bugs, which must be addressed to avoid risk.There is general agreement that TXHASH is an acceptable theoretical approach, and it may be worth drafting a prototype of it. However, CTV is preferred as a first step for pragmatic engineering and availability timeline reasons. If TXHASH were to take 2 years to develop and review, and then 1 year to activate, having CTV within 1 year would put Bitcoin in a much better place, with applications built over the next few years enhanced in the future by TXHASH's availability.Bringing CTV to an implemented state of near-unanimous "we could do this, technically" is good for concretely driving the process of review for any covenant proposals forward. The proposal suggests decomposing the operations of CTV and ANYPREVOUT into their constituent pieces and reassembling their behavior programmatically. The proposal suggests OP_TXHASH and OP_CHECKSIGFROMSTACKVERIFY as alternative proposals that can mimic most of the properties of CTV. There are caveats to the proposal, such as the inability to implement TXHASH in legacy script and potential difficulties with upgrading TXHASH. However, these difficulties can be mitigated by designing a robust set of TXHASH flags from the start. The proposal also considers how these opcodes may interact with future opcodes such as CAT, rolling SHA256 opcodes, or how it might interface with other covenant opcodes that may do things like directly push input or output amounts onto the stack for computation purposes.Overall, there is much to consider in terms of the potential impact of these proposals on the Bitcoin community and its future development. Despite concerns about testing timelines and additional upgrades required, stakeholders agree that the priority should be on developing and testing these solutions thoroughly before rushing into implementation on mainnet.
Updated on: 2023-06-15T15:34:39.091212+00:00