This BIP describes a new opcode for the purpose of checking cryptographic
signatures in bitcoin scripts against data from the stack.
## Summary
When verifying taproot script spends having leaf version 0xc0 (as defined in
[BIP 342]), we propose `OP_CHECKSIGFROMSTACK` to replace `OP_SUCCESS204`
(0xcc).
`OP_CHECKSIGFROMSTACK` has semantics similar to `OP_CHECKSIG`, as specified
below. Briefly, it pops 3 elements from the stack: a 32-byte public key, a
message, and a signature. If the signature is valid for that public key and
message, 1 is pushed to the stack. If the signature is the empty vector, 0 is
pushed to the stack, and otherwise script execution fails.
Only 32-byte keys are constrained. Similar to [BIP 341] unknown key types, for
other key lengths no signature verification is performed and it is considered
successful.
## Specification
* If fewer than 3 elements are on the stack, the script MUST fail and terminate immediately.
* The public key (top element), message (second to top element), and signature (third from top element) are read from the stack.
* The top three elements are popped from the stack.
* If the public key size is zero, the script MUST fail and terminate immediately.
* If the public key size is 32 bytes, it is considered to be a public key as described in [BIP 340]:
* If the signature is not the empty vector, the signature is validated against the public key and message according to [BIP 340]. Validation failure in this case immediately terminates script execution with failure.
* If the public key size is not zero and not 32 bytes; the public key is of an unknown public key type. Signature verification for unknown public key types succeeds as if signature verification for a known public key type had succeeded.
* If the script did not fail and terminate before this step, regardless of the public key type:
* If the signature is the empty vector: An empty vector is pushed onto the stack, and execution continues with the next opcode.
* If the signature is not the empty vector:
* The opcode is counted towards the sigops budget as described in [BIP 342].
* A 1-byte value 0x01 is pushed onto the stack.
## Design Considerations
1. Message hashing: [BIP 340] is compatible with any size of message and does not require it to be a securely hashed input, so the message is not hashed prior to [BIP 340] verification.
2. Lack of verify semantics: Adding a single opcode for this purpose keeps the implementation and design simple. An earlier draft had a verify variant as a NOP upgrade, and if this functionality is later brought to legacy scripts, that would be a good time to add a verify variant.
3. Add/multisig: No concession is made to `OP_CHECKMULTISIG` or `OP_CHECKSIGADD` semantics with `OP_CHECKSIGFROMSTACK`. In Tapscript, add semantics can be implemented with 1 additional vByte per key (`OP_TOALTSTACK OP_CHECKSIGFROMSTACK OP_FROMALTSTACK OP_ADD`).
4. Splitting R/S on the stack: Implementing split/separate signatures is left as an exercise for other bitcoin upgrades, such as [BIP 347] (`OP_CAT`).
5. APO-style ([BIP 118]) Taproot internal key: Rather than introducing an additional key type in this change, we suggest implementing `OP_INTERNALKEY` ([BIP 349]) or separately introducing that key type for all Tapscript signature checking operations in a separate change.
## Resource Limits
These opcodes are treated identically to other signature checking opcodes and
count against the sigops and budget.
## Motivation
### LN Symmetry
When combined with [BIP 119] (`OP_CHECKTEMPLATEVERIFY`/CTV),
`OP_CHECKSIGFROMSTACK` (CSFS) can be used to implement Lightning Symmetry
channels. The construction `OP_CHECKTEMPLATEVERIFY <pubkey>
OP_CHECKSIGFROMSTACK` with a spend stack containing the CTV hash and a
signature for it is logically equivalent to `<bip118_pubkey> OP_CHECKSIG` and
a signature over `SIGHASH_ALL|SIGHASH_ANYPREVOUTANYSCRIPT`. The
`OP_CHECKSIGFROMSTACK` construction is 8 vBytes larger.
Summary of alternatives:
* CTV+CSFS is the minimal functionality needed for Lightning Symmetry but requires the use of an `OP_RETURN` for data availability
* APO is the original design for Lightning Symmetry and uses the taproot annex for data availability.
* LNHANCE (CTV+CSFS+IKEY+PC) is the most efficient and direct way currently designed to implement Lightning Symmetry.
### Delegation
Using a script like:
`<pubkey> SWAP IF 2 PICK SWAP CSFS VERIFY ENDIF CHECKSIG`
either direct verification or delegation can be achieved by the following
unlock stacks: `<sig> 0` or `<dsig> <dpubkey> <sig> 1`
### Advanced delegation when combined with [OP_PAIRCOMMIT] or OP_CAT
Using a script like:
`CLTV OVER PAIRCOMMIT TOALT CHECKSIGVERIFY FROMALT <pubkey> CSFS`
or:
`CLTV SHA256 OVER CAT TOALT CHECKSIGVERIFY FROMALT <pubkey> CSFS`
