Author: Anthony Towns 2022-02-17 14:27:27
Published on: 2022-02-17T14:27:27+00:00
The bitcoin-dev mailing list has been discussing the potential for combining the TXHASH proposal with CAT and/or rolling SHA256 opcodes to create something that can be flexibly programmed at redemption time. The aim is to create a system that requires very few bytes to express common use cases, is efficient to execute even if used maliciously, is hard to misuse accidentally, and can be cleanly upgraded via soft fork in the future if needed.The discussion also covered the usefulness of "CAT" and "CHECKSIGFROMSTACK" in practical applications, leading to debate about the need for a more ideal programming language. However, some members are not convinced that the proposal covers all potential future needs, particularly when it comes to SIGHASH_GROUP. The ideal solution would be a general/flexible/expressive but expensive way of doing whatever scripting is required, followed by adding specific features as new ideas get discovered and widely deployed.A new cost function would need to be defined to make it "cheap to use", which would require a soft fork. Additionally, some experiments may still require a soft fork to expose certain data. However, the use of simplicity code could improve the soft fork process by providing on-chain evidence of its usefulness and allowing for greater confidence in the implementation's correctness.Both CTV via legacy script and the use of TXHASH may be useful in saving vbytes compared to other methods. The author discusses the advantages and disadvantages of using CTV versus TXHASH for transaction validation. While CTV appears to be more flexible, it may not be ready for deployment on mainnet due to a lack of third-party experimentation. Additionally, the author considers the pros and cons of bundling CTV with APO and SIGHASH_GROUP, ultimately concluding that they should only be bundled if they are fully specced, implemented, and tested by the time CTV is ready for deployment. The author also briefly touches on the possibility of using TXHASH, CAT, and SHA256 for limited transaction reflection and mentions the importance of committing to input count and input index to prevent losing UTXOs to fees.
Updated on: 2023-05-22T16:50:16.663974+00:00