Published on: 2022-02-17T14:50:53+00:00
In a technical discussion on the bitcoin-dev mailing list, various topics related to transaction introspection, Discreet Log Contracts (DLCs), and programmable systems were debated. It was noted that Discreet Log Contracts provide interesting oracle behavior without transaction introspection, but CSFSV allows for pubkey delegation, which was not previously mentioned. The potential combination of the TXHASH proposal with CAT and rolling SHA256 opcodes to create a programmable system at redemption time was discussed. The usefulness of "CAT" and "CHECKSIGFROMSTACK" in practical applications and the need for a more ideal programming language were also debated.There were concerns raised about whether the proposal covers all future needs, particularly regarding SIGHASH_GROUP. The advantages and disadvantages of using CTV versus TXHASH for transaction validation were discussed. It was noted that while CTV appears to be more flexible, there is a lack of third-party experimentation, making it potentially unsuitable for deployment on mainnet. The pros and cons of bundling CTV with APO and SIGHASH_GROUP were considered, with the conclusion that they should only be bundled if fully specced, implemented, and tested.Jeremy Rubin highlighted the differences between CTV and TXHASH, noting that CTV requires the contract to be fully enumerated and is non-recursive, limiting its applicability. Rusty Russell agreed with this assessment, emphasizing the importance of making tools as clean and clear as possible. There was a discussion about the possibility of using CTV in recursive covenants, with concerns raised about the limitations of fully enumerating contracts and the need to know the set of pairs in advance. It was suggested that iterative covenants are possible with CTV and just as powerful, though technically finite.Russell O'Connor proposed decomposing CTV and ANYPREVOUT into their constituent pieces and programmatically reassembling their behavior. Further decomposition of OP_TXHASH and defining bits for controlling various aspects of a transaction was suggested. The use of SHA256() of scripts instead of the scripts themselves was also proposed. There were discussions about the potential enhancements of Bitcoin Script's functionality, including the combination of TXHASH with CAT and/or rolling SHA256 opcodes. The need for a flexible and expressive scripting system was emphasized, with the possibility of adding specific features as new ideas emerge.The efficiency and usefulness of CTV in comparison to a more general covenant system were debated, with the argument that if CTV is efficient for expressing useful patterns like vaults, it should not be considered technical debt. The importance of considering the long-term implications of design choices was highlighted. Concerns were raised about the complexity and potential challenges associated with implementing CTV, such as technical debt and the need for additional hash formats. However, it was noted that CTV is currently the most practical approach for vaulting and has a low maintenance burden.There were discussions about the potential risks and challenges associated with implementing CTV, such as technical debt and the need for additional hash formats. The possibility of creating complex or recursive covenants using TXHASH and CSFSV was debated, with differing opinions on whether CAT is needed for such constructions. The availability of custom signets with CTV was questioned, with the absence of readily available faucets noted as a possible limitation. The efficiency and usefulness of CTV in comparison to a more general covenant system were discussed, along with the potential benefits and limitations of CTV's hash structure. The proposal of an alternative way to extend the set of txflags for TXHASH was considered, highlighting the benefits and potential challenges of this approach.The discussion on covenant opcodes involved debates about technical debt, soft fork processes, and the risks associated with them. Some stakeholders advocated for implementing CTV, while others suggested that TXHASH+CSFSV would provide more value and enable oracle signature verification. The complexity of these proposals and the potential for quadratic hashing bugs were raised as concerns. It was agreed that while TXHASH is a theoretical approach worth exploring, CTV is preferred for its practicality and availability timeline. The proposal suggested decomposing the operations of CTV and ANYPREVOUT and reassembling their behavior programmatically. Alternative proposals like OP_TXHASH and OP_CHECKSIGFROMSTACKVERIFY were also considered.Overall, the discussions on implementing a CTV opcode in Bitcoin Script involved considerations of efficiency, usefulness, technical debt, and long-term implications. There were debates about the viability of creating complex or recursive covenants using existing opcodes and the need for additional ones. The availability of custom signets with CTV and the challenges associated with testing and upgrading were also discussed. Stakeholders emphasized the importance of thoroughly developing and testing these solutions before implementation on the mainnet.The proposal suggested the introduction of new opcodes to verify signatures on messages signed by oracles for oracle applications. These opcodes could be combined with multiple calls to TXHASH to create signatures that commit to specific subsets of transaction data.
Updated on: 2023-08-02T05:27:45.946150+00:00