Exploring Bitcoin Covenants Part 4: The Power of OP_CAT Combined with OP_CHECKSIGFROMSTACK
OP_CHECKSIGFROMSTACK enables verification of signatures across any arbitrary data, while OP_CAT merges stack elements into unified messages. When utilized in tandem, these opcodes empower Bitcoin scripts to validate transaction architecture during spending operations, eliminating the need for pre-signed key handling or additional consensus modifications beyond implementing these two fundamental opcodes.
This represents the fourth installment in our comprehensive technical series exploring Bitcoin covenants, presented by Cointelegraph Research. You can access the preceding installment by clicking here.
The opcodes discussed in this section do not, by themselves, provide complete covenant capabilities. Rather, they serve as fundamental components that enable covenant construction when used alongside additional opcodes or scripting elements.
OP_CHECKSIGFROMSTACK (OP_CSFS) and OP_CAT
OP_CSFS represents a proposed opcode designed to enable Bitcoin script to authenticate signatures covering arbitrary messages provided on the stack. This differs fundamentally from OP_CHECKSIG, which authenticates signatures covering the spending transaction in accordance with the currently active SIGHASH mode. Through enabling signature authentication for data beyond serialized transaction information, OP_CSFS facilitates a wider range of constructions, including oracle-dependent scripts where external entities sign off-chain messages representing real-world occurrences. As an illustration, a trusted oracle might publish Schnorr signatures covering messages that encode external event outcomes, while an OP_CSFS-enabled script could make payments conditional upon the presence of a valid oracle signature.
In isolation, OP_CSFS cannot implement covenants. While it can authenticate external information, it lacks the capability to bind that information to the structure of the spending transaction. Establishing that binding necessitates OP_CAT.
OP_CAT represents a proposed opcode that facilitates the concatenation of two stack values to create a single byte sequence rather than maintaining two separate ones. When used in conjunction with OP_CSFS, it enables the script to construct selected transaction fields into a canonical message and authenticate that a supplied signature commits to that particular message.
OP_CSFS combined with OP_CAT can accomplish introspection by requiring the spender to supply transaction details on the witness stack. When both OP_CSFS and OP_CHECKSIG validate successfully for an identical signature, this proves that accurate transaction details have been supplied to the witness stack and can be subjected to further analysis. Through verification of the transaction against a predetermined template, a covenant construction analogous to OP_CTV can be implemented. Two minimal assembly examples demonstrate this mechanism:
OP_CAT + Schnorr Tricks
Through utilization of OP_CAT, covenant-type constructions can be implemented under Taproot even without OP_CSFS by leveraging the interaction between Schnorr signatures and the Taproot sighash rules specified in BIP 341. This construction repurposes OP_CHECKSIG from its typical function of authenticating private key ownership into a mechanism for transaction introspection.
A schnorr signature consists of a pair ⟨R, s⟩. In typical scenarios, this schnorr signature is produced by selecting a secret nonce k, calculating the point R = kG, and computing the signature value s as a function of both the message hash and the private key. The verifying party then validates the signature pair ⟨R, s⟩ against a public key P and the message undergoing signing. The random nature of k guarantees that s remains unpredictable and cannot be reproduced without possession of the private key.
This introspection technique functions by removing randomness through fixing certain variables beforehand. Rather than selecting R randomly during the signing process, the script commits to a predefined value of R and to a fixed public key P. Since Schnorr verification adheres to a deterministic equation, it becomes feasible to construct these values such that the signature scalar s must equal a hash of particular transaction parameters.
The spending party supplies R and s on the witness stack. OP_CAT merges them into the signature pair ⟨R, s⟩ in the format that OP_CHECKSIG requires. The script then validates this against the hardcoded public key P. Since R and P are fixed to the base point G, OP_CHECKSIG will only validate the pair when s equals the SHA256 hash of the actual transaction data calculated by the protocol. The spending party cannot construct an s that satisfies OP_CHECKSIG unless it authentically reflects the genuine transaction data. The spending party must grind the transaction data until its SHA256 hash terminates in a particular byte, which requires approximately 256 attempts on average and introduces negligible computational cost.
Through this method, OP_CHECKSIG transitions from authenticating ownership of a secret private key to instead enforcing that the transaction conforms to a particular template. The resulting expressiveness is broadly equivalent to OP_CTV.
Since this methodology relies upon Schnorr signatures and the taproot sighash algorithm, it is applicable exclusively to SegWit v1 outputs and cannot be extended to SegWit v0 outputs which utilize the BIP-143 digest and ECDSA signatures.
In the next installment of this series we will begin our exploration of OP_CCV, which offers even greater capabilities than OP_CSFS and OP_CAT when combined.