Draft BIP: OP_TXHASH and OP_CHECKTXHASHVERIFY

The email is from Steven and he is discussing the concept of a TxHash (Transaction Hash) and its formalization. He has worked on a specification and has been gathering feedback for several weeks. The full BIP (Bitcoin Improvement Proposal) text can be found in the attachment and also on this GitHub link: https://github.com/bitcoin/bips/pull/1500.The BIP specifies the concept of a TxFieldSelector, which is a serialized data structure used to select data inside a transaction. It defines various global fields such as version, locktime, number of inputs, number of outputs, current input index, and current input control block. It also specifies the fields available for each input and output. Additionally, it introduces support for selecting inputs and outputs based on certain criteria, including all in/outputs, a single in/output at the same index as the input being executed, any number of leading in/outputs, and up to 64 individually selected in/outputs.The BIP introduces two new opcodes: OP_TXHASH and OP_CHECKTXHASHVERIFY. OP_TXHASH is enabled only in tapscript and takes a serialized TxFieldSelector from the stack and pushes on the stack a hash committing to all the selected data. OP_CHECKTXHASHVERIFY is enabled in all script contexts and expects a single item on the stack, interpreted as a 32-byte hash value concatenated with a serialized TxFieldSelector. Execution fails if the hash value in the data push doesn't match the calculated hash value based on the TxFieldSelector.The BIP also addresses concerns around resource usage, particularly related to quadratic hashing. It proposes a potential caching strategy to prevent excessive hashing. It limits individual selection to 64 items and suggests that selecting "all" in/outputs can mostly use the same caches as sighash calculations. It also mentions the possibility of storing intermediate SHA256 contexts for prefix hashing to minimize the number of items that need to be hashed repeatedly.The email discusses the achievements of this proposal. It mentions that the default TxFieldSelector is functionally equivalent to OP_CHECKTEMPLATEVERIFY, making it a strict upgrade of BIP-119. The flexibility of selecting transaction fields and in/outputs makes this construction more useful in designing protocols where users want to add fees to their transactions without breaking a transaction chain or when constructing transactions together with specific conditions on in/outputs. Additionally, OP_TXHASH, along with other opcodes like OP_CHECKSIGFROMSTACK, could be used as a replacement for complex sighash constructions.There are some open questions mentioned in the email. One question is whether the proposal sufficiently addresses concerns around resource usage and quadratic hashing. Another question relates to including the TxFieldSelector as part of the hash, which would affect the ability to prove equality of fields. A potential solution is suggested, which involves assigning additional bits in the "in/output selector" bytes to include the TxFieldSelector in the hash. The email also seeks general feedback on the proposal and whether it should be implemented as a softfork.In conclusion, Steven is seeking wider feedback and community interest in this proposal for a TxHash concept. He is willing to spend time formalizing the BIP and working on an implementation for Bitcoin Core if there is community interest.