Published on: 2022-05-14T13:32:18+00:00
In a recent discussion on the bitcoin-dev mailing list, the implementation of CAT+CSFS for validating oracle messages and pubkey delegation was discussed. The primary purpose of this proposal would be to validate these messages, with covenants serving as a secondary function to gather user data. It was emphasized that the development of new opcodes should not happen without validating the current ones.Various opinions were shared regarding different opcode proposals. Anthony Towns stated that CTV and APO are weaker in terms of what can be done with them, while CAT/CSFS lacks ease of use and bug prevention. OP_TX was also considered to have less clean and maintainable validation code. Russell O'Connor expressed his belief that recursive covenants are necessary for programmable money, but they should be used properly and understood by users to avoid misuse.The use of OP_CAT in tapscript was also discussed. While OP_CAT alone does not enable covenants, non-recursive covenants can be enabled with it. However, it is still uncertain whether recursive covenants can be achieved. ZmnSCPxj suggested that hijacking the ECDSA checksig operation from a parallel, legacy input could potentially enable the calculations needed for recursive covenants, but this has not been accomplished yet.The email thread also touched upon the removal of OP_CAT from Bitcoin and its potential re-enabling in a soft fork. Concerns were raised about excessive memory usage and security risks associated with recursive scripts. The concept of negative fee transactions, where the receiver pays all transaction costs, was also mentioned.There were discussions about using OP_SUBSTR or OP_SPLIT instead of OP_CAT for script covenant operations. These alternatives were considered better as they ensure smaller script sizes and only one byte as the smallest unit in the script. It was clarified that OP_CAT does not by itself make all covenant opcodes recursive, but it enables any opcode to be recursive.Overall, the discussions highlighted the importance of carefully considering factors such as functionality, efficiency, bug prevention, and clean validation code when proposing and implementing opcodes. The potential risks and benefits of recursive covenants were also explored, with the need for thorough review and testing before their implementation.In a conversation between Jorge and ZmnSCPxj, the possibility of enabling covenants using OP_CAT in Bitcoin was discussed. Recursive covenants were highlighted as being close to true Turing-completeness, which poses a risk of denial-of-service attacks on the network. Non-recursive covenants can be enabled with OP_CTV and SIGHASH_ANYPREVOUT. However, limiting opcode processing would reduce the system from Turing-complete to total programming without codata. The safety of total-with-codata needs to be proven before enabling such opcodes.The removal of OP_CAT was due to its potential to cause an O(2^N) memory usage problem. It was suggested that re-enabling it could be achieved through TapScript by adding restrictions. Creating a new opcode, OP_CAT2, is unnecessary unless it is significantly different. Alternatively, other string-based functions like OP_SUBSTR or OP_SPLIT can be utilized. Modifying sighashes can also address the issue of transaction costs being paid by the sender instead of the receiver. For example, a "negative fee transaction" can be created using SIGHASH_SINGLE | SIGHASH_ANYONECANPAY.The discussion originated from the context of P2SH, where the sender was paying for the receiver's security with k-of-n multisignature. This led to the creation of OP_EVAL and the P2SH concept. However, concerns about recursive covenants prompted changes to modern P2SH, making it "just a template" without any actual OP_EVAL. Re-enabling OP_CAT would require a hardfork, but a soft-fork approach using TapScript could enable the same opcode. Quantum-computing-break concerns can be addressed by utilizing a new SegWit version.It was noted that OP_CAT does not implement covenants itself but creates recursive covenants when combined with other covenant opcodes. The simplicity proposal was considered the best among all covenant proposals but requires a new scripting language that is more challenging to review and test. Speedy covenants, on the other hand, have been implemented for a longer time and should be easier to deploy. Deploying other covenant proposals later is not incompatible with this proposal.While the removal of OP_CAT was not directly related to enabling covenants, discussions around P2SH highlighted the need for improved security for receivers without burdening the sender. The solution became OP_EVAL and P2SH, but concerns about recursive covenants arose. Re-enabling OP_CAT would require a hardfork, but a new OP_CAT2 could be introduced as a soft fork. Taproot could also enable the same opcode in a soft-fork manner.
Updated on: 2023-08-02T06:27:28.079397+00:00