This is Part 4 in the technical article series about Bitcoin covenants by Cointelegraph Research. To read the previous article, click here.
The following opcodes do not independently implement full covenant functionality. Instead, they are building blocks for constructing covenants when combined with other opcodes or script elements.
OP_CHECKSIGFROMSTACK (OP_CSFS) and OP_CAT
OP_CSFS is a proposed opcode that would allow Bitcoin script to verify signatures over arbitrary messages supplied on the stack. It is different from OP_CHECKSIG, which verifies signatures over the spending transaction according to the active SIGHASH mode. By enabling signature verification for data other than the serialized transaction details, OP_CSFS enables a broader class of constructions, including oracle-based scripts where an external party signs off-chain messages that represent real-world events. For example, a trusted oracle could publish Schnorr signatures over messages that encode external outcomes, and an OP_CSFS-based script could condition payments on the presence of a valid oracle signature.
On its own, OP_CSFS does not implement covenants. It can authenticate external data, but it does not bind that data to the structure of the spending transaction. That binding requires OP_CAT.
OP_CAT is a proposed opcode that enables the concatenation of two values on the script stack to form a single byte sequence instead of two distinct ones. When combined with OP_CSFS, it allows the script to assemble selected transaction fields into a canonical message and verify that a provided signature commits to that message.
OP_CSFS and OP_CAT taken together can perform introspection by compelling the spender to provide transaction details on the witness stack. If both OP_CSFS and OP_CHECKSIG succeed for the same signature, it proves that the correct transaction details have been passed on to the witness stack and can be further reasoned about. By checking the transaction against a predefined template, a covenant construction, similar to OP_CTV, can be enforced. Two minimal assemblies show how this works:
OP_CAT + Schnorr Tricks
Using OP_CAT, covenant-like constructions can be enforced under Taproot without OP_CSFS by exploiting how Schnorr signatures interact with the Taproot sighash rules defined in BIP 341. The construction repurposes OP_CHECKSIG which is ordinarily used to authenticate ownership of a private key, to a transaction introspection tool.
A schnorr signature is a pair ⟨R, s⟩. Under normal circumstances, this schnorr signature is generated by selecting a secret nonce k, deriving the point R = kG, and computing the signature value s as a function of the message hash and the private key. The verifier then checks the signature pair ⟨R, s⟩ against a public key P and the message being signed. The randomness of k ensures that s is unpredictable and non-reproducible without knowledge of the private key.
The introspection trick works by eliminating randomness by fixing some of these variables in advance. Instead of choosing R randomly during signing, the script commits to a predetermined value of R and to a fixed public key P. Because Schnorr verification follows a deterministic equation, it becomes possible to construct these values so that the signature scalar s must equal a hash of specific transaction parameters.
The spender provides R and s on the witness stack. OP_CAT concatenates them into the signature pair ⟨R, s⟩ in the format OP_CHECKSIG expects. The script verifies this against the hardcoded public key P. Because R and P are fixed to the base point G, OP_CHECKSIG will only accept the pair if s equals the SHA256 hash of the actual transaction data computed by the protocol. The spender cannot fabricate an s that passes OP_CHECKSIG unless it genuinely reflects the real transaction data. The spender must grind the transaction data until its SHA256 hash ends in a specific byte, which takes roughly 256 attempts on average and adds negligible cost.
In this way, OP_CHECKSIG is no longer used to authenticate ownership of a secret private key but instead to enforce that the transaction matches a specific template. The expressiveness is broadly comparable to OP_CTV.
Because this approach depends on Schnorr signatures and the taproot sighash algorithm, it applies only to SegWit v1 outputs and does not extend to SegWit v0 outputs which uses the BIP-143 digest and ECDSA signatures.
In our next article we will commence our discussion of OP_CCV, which is even more capable than OP_CSFS and OP_CAT combined.