Background
Bitcoin script is a stack-based verification language. As a result of it is a verification language any operation out there 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 straight inspected by script.
BIP 340 signatures encompass (R,s) satisfying the operate 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 are able to pressure s to be equal to hash(G || G || m) + 1. Utilizing CAT, we are able to 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 are able to then additional require the spend stack to offer m.
Verifying transaction parts
BIP 341 signature hashes are composed of inner hashes of many elements 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
