TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT



Summary:

The email conversation between Russell O'Connor and Jeremy Rubin revolves around the implementation of a new opcode for Bitcoin called CTV. While Jeremy expresses concerns about potential issues with combinatorial growth of flags and its impact on testing, Russell argues that CTV's simplicity makes it a low-risk change compared to other covenant proposals. They also discuss the eventual adoption of TXHASH and the time it might take to develop, test, and release. However, in the meantime, they recognize the need for a vault strategy that doesn't require presigning transactions with ephemeral keys or multisig configurations. They also touch upon technical debt and soft fork processes and debate whether implementing CTV opcode that may eventually be obsoleted by TXHASH would yield good value from a soft fork process.Russell presents an argument in favor of CTV being added to legacy script since they cannot use TXHASH in legacy script. He also argues that if OP_CTV ends up being the most practical approach for vaulting, then technical debt may not be an applicable term. The developers discuss the different types of opcodes required for realizing full covenanting power and the timeline it would take to ready something like TXHASH. Overall, Jeremy prefers CTV as a first step for pragmatic engineering and availability timeline reasons while acknowledging that TXHASH is an acceptable theoretical approach. Bringing CTV to an implemented state of near-unanimous agreement is seen as good for concretely driving the review process of any covenant proposals forward, irrespective of whether it ultimately gets activated.In addition to CTV, the developers are also discussing an alternative proposal to the CheckTemplateVerify (CTV) and AnyPrevOut (APO) proposals called OP_TXHASH and OP_CHECKSIGFROMSTACKVERIFY. This proposal decomposes CTV and APO's operations into their constituent parts to allow for more programming flexibility. However, replicating CTV and APO's behavior requires more bytes than the custom-built proposals themselves. Furthermore, TXHASH is not NOP-compatible and can only be implemented within tapscript. However, the proposal doesn't preclude the possibility of having CTV added to legacy script while having TXHASH added to tapscript.


Updated on: 2023-06-15T15:36:42.682389+00:00