OP_CHECKSIGFROMSTACK opcode overview

Author: Bitcoin Optech

Source: https://bitcoinops.org/en/topics/op_checksigfromstack/

OP_CHECKSIGFROMSTACK (OP_CSFS) is an opcode that exists on the ELEmentsProject.org sidechain and has sometimes been proposed for implementation on Bit. This opcode can check a signature against an arbitrary message. It takes three parameters: a signature, a message, and a public key.

The existing Bit signature checking opcodes, like OP_CHECKSIG, do not allow specifying an arbitrary message; they verify the signature against the data derived from the transaction executing the signature check opcode, allowing them to verify that a signature matches a public key and that the private key behind that public key was used to authorize the spending of that data (the public key and signature). This is powerful enough to secure Bit's UTXO set, but prevents using digital signatures to attest to other types of data within the Bit system. With OP_CSFS, we can verify signatures against arbitrary messages, enabling several new features for Bit users:

• Paying for signatures: If Alice controls a private key that can sign a transaction paying Bob, Bob can use OP_CSFS to trustlessly commit to paying Alice for her signature.

  However, recent protocols involving paying for signatures typically assume the use of "adaptor signatures", which are more private and require less Block space.

• Delegation: Alice may want to delegate authorization for spending her funds to Bob without explicitly creating an on-Chain transaction moving the funds to a 1-of-2 multisig address between them. If Alice designs her script to support this kind of delegation, she can put Bob's public key in a message and use OP_CSFS to prove she has delegated spending authority to that public key.

  An alternative approach that can achieve the same effect is graftroot, which is more private, flexible, and Block space efficient, but requires a soft fork and has received little attention so far.

• Oracles: An oracle is a participant who agrees to sign a message attesting to the outcome of an event (e.g. a sporting event). Two or more users can then deposit funds into a script using OP_CSFS that triggers a payout based on the outcome attested to by the oracle.

  Recent focus on oracle-backed contracts includes "Discreet Log Contracts (DLCs)", which are more private and Block space efficient.

• Anti-double-spend escrow: A service provider can commit to never spending a particular UTXO of theirs, to encourage their payees to accept their unconfirmed transactions as reliable payment. To prove their good intentions, the service provider can use OP_CSFS to commit to paying a security deposit to any user who can prove two different signatures were created using the same key to spend the same UTXO.

  This is analogous to "single-show signatures", which allow anyone seeing two signatures from the same key to derive the private key used to create them and spend any other funds protected by that key.

• Transaction introspection: If the same public key and signature pair is valid for both OP_CSFS and OP_CHECKSIG, it means the message passed to OP_CSFS is exactly the same as the serialized transaction (and other data) implicitly used by OP_CHECKSIG. This allows placing a verified spending transaction on the script evaluation stack and using other opcodes to run checks on the actual spending transaction.

  For example, if OP_CSFS had been enabled in 2015 and 2016, we could have written a validation script implementing the features of BIP65 OP_CHECKLOCKTIMEVERIFY (CLTV script absolute time locks) and BIP112 OP_CHECKSEQUENCEVERIFY (CSV script relative time locks) without requiring a dedicated consensus change.

  Looking forward, OP_CSFS could also be used to write scripts implementing the proposed SIGHASH_ANYPREVOUT feature, as well as other proposed opcodes like OP_CHECKTEMPLATEVERIFY. Additionally, OP_CSFS could be used to create "covenants" - constraints on how a set of Bits can be spent - such as "vault contracts" that restrict the script pubkeys of spending transactions to limit the risk of theft.

  The power of OP_CSFS lies in providing complete introspection of the transaction being executed, in a fully general way. Its downside is that it requires adding the full transaction copy to the stack, which could greatly increase transaction size. In contrast, some single-purpose introspection opcodes like CLTV and CSV have minimal overhead, but each new introspection opcode requires a consensus change and carries the risk of rendering some users' funds unspendable if it later falls out of use (even if it seems obsolete).