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 offered to be used within the script which produce a pre-determined output. As Andrew Poelstra says – operations could be run ahead or backward.
At the moment, bitcoin scripts have 3 methods to confirm the transaction by which they’re spent:
- Requiring a selected
nLockTimesubject on the transaction (OP_CHECKLOCKTIMEVERIFY) - Requiring a selected
nSequencesubject on the enter (OP_CHECKSEQUENCEVERIFY) - Requiring a signature over a hash of the transaction (
OP_CHECKSIGand its variants)
When individuals focus on “including covenants” to bitcoin, they consult with including further methods to confirm the spending transaction, mostly restrictions on the outputs the transaction will make.
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 information for that hash could be straight inspected by script.
BIP 340 signatures encompass (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 drive 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 elements of the transaction being verified. Utilizing CAT, a bitcoin spend script can require the spend stack to incorporate the unconstrained inputs to the signature hashes and concatenate them with script-provided constrained parts to confirm that the constrained parts match the precise transaction. Which means that any datum included within the signature hash could be constrained individually utilizing CAT.
Thus, by together with (for instance) a hash of transaction outputs in a locking script, an OP_CAT-based covenant script can require the caller to supply all different transaction information and the hashes described above and require that the spending transaction has the required outputs. An extra covenant in bitcoin script.
Full working code utilizing these strategies could be seen in @rot13maxi’s Purrfect Vaults
