OP_CHECKSIGFROMSTACK and OP_CAT

OPCSFS authenticates signatures over arbitrary data. OPCAT concatenates stack values into a single message. Together, they let Bitcoin scripts verify transaction structure at spend time, without pre-signed key management or new consensus rules beyond the two opcodes themselves.

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.

OPCSFS is a proposed opcode that would allow Bitcoin script to verify signatures over arbitrary messages supplied on the stack. It is different from OPCHECKSIG , 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, OPCSFS 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 OPCSFS -based script could condition payments on the presence of a valid oracle signature.

On its own, OPCSFS 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 OPCAT .

OPCAT 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 OPCSFS , it allows the script to assemble selected transaction fields into a canonical message and verify that a provided signature commits to that message.

OPCSFS and OPCAT taken together can perform introspection by compelling the spender to provide transaction details on the witness stack. If both OPCSFS and OPCHECKSIG 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 OPCTV , can be enforced. Two minimal assemblies show how this works:

OPCAT + Schnorr Tricks

Using OPCAT , covenant-like constructions can be enforced under Taproot without OPCSFS by exploiting how Schnorr signatures interact with the Taproot sighash rules defined in BIP 341 . The construction repurposes OPCHECKSIG 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. OPCAT concatenates them into the signature pair ⟨ R, s ⟩ in the format OPCHECKSIG expects. The script verifies this against the hardcoded public key P . Because R and P are fixed to the base point G , OPCHECKSIG 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 OPCHECKSIG 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, OPCHECKSIG 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 OPCTV .

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 OPCCV , which is even more capable than OPCSFS and OPCAT combined.

Cointelegraph is committed to providing independent, high-quality journalism across the crypto, blockchain, AI, and fintech industries.

All news, reviews, and analyses are produced with full journalistic independence and integrity. For more details on our standards and processes, please read our Editorial Policy .

新闻图片