Combined CTV/APO into minimal TXHASH+CSFS

The discussion revolves around the handling of OP_TXHASH in the context of blockchain soft forks, emphasizing the need for scripts to clearly define how they accept signatures on various transaction hashes. A new stance has been introduced, suggesting that OP_TXHASH should be viewed as a single fragment with only one interpretation at each soft fork level. This approach necessitates that if multiple transaction hashes are to be accepted, they must be explicitly specified within the script's code. The rationale behind this methodology is elaborated through a shared resource, which outlines the procedure for selecting the OP_TXHASH mode at the time of expenditure.

The argument further unfolds by comparing the proposed handling of OP_TXHASH with existing signature operations (sigops). In traditional sigops, the hash method employed during a transaction can be determined at the time of spending, thanks to the integrated process of hashing and signature verification. However, the separation of these two processes—hashing and signature validation—calls for a predefined hash method in the output script. This change is partly due to the introduction of a new key type under bip118, distinguished from existing key types by its commitment to new spendable modes.

This conversation underscores an important shift in blockchain protocol development, highlighting the trade-offs between upgradeability of the OP_TXHASH feature and the simplicity of specifying hash types or computing them within scripts at the time of transaction. The emphasis on predefining hash methods aligns with broader goals of ensuring security and clarity in transaction execution, particularly in the evolving landscape of soft fork implementations.