Background
Bitcoin script is a stack-based verification language. As a result of it is a verification language any operation accessible within the language can be utilized to both take inputs and produce an output for later use within the script, or require inputs to be supplied to be used within the script which produce a pre-determined output. As Andrew Poelstra says – operations might be run ahead or backward.
Bitcoin signature checking operations internally hash the transaction being verified. As a result of the hashing and signing are contained in a single operation, neither the signature hash nor the enter knowledge for that hash might be immediately inspected by script.
BIP 340 signatures include (R,s) satisfying the perform s⋅G = R + hash(R || P || m)⋅P the place m is the signature hash, P is the signer’s public key, and G is the secp256k1 generator level.
Getting the signature hash on the stack
As Andrew Poelstra describes intimately, by setting R and P equal to G, we will pressure s to be equal to hash(G || G || m) + 1. Utilizing CAT, we will deconstruct the 64-byte signature into its R and s values, and if we additional require the spend stack to incorporate the primary 31 bytes of hash(G || G || m) (floor till the final byte would have been 0x00), we will then additional require the spend stack to supply m.
Verifying transaction parts
BIP 341 signature hashes are composed of inside hashes of many components of the transaction being verified. Utilizing CAT, a bitcoin spend script can require the spend stack to incorporate the unconstrained inputs to those hashes and concatenate them with script-provided constrained parts to confirm that the constrained parts match the precise transaction. Which means any datum included within the signature hash might be constrained individually utilizing CAT.
Full working code utilizing these strategies might be seen in @rot13maxi’s Purrfect Vaults