As we delve further into this series, spotlighting various sophisticated covenant proposals, CHECKSIGFROMSTACK (CSFS) represents a pivotal development. Introduced by Brandon Black and Jeremy Rubin through BIP 348, this isn’t exactly a covenant, but it plays an important role in enhancing and working alongside them. Let’s explore the mechanics and significance of CSFS in the realm of Bitcoin scripts.
Before dissecting how CSFS functions, it’s crucial to grasp the fundamentals of Bitcoin scripting. Bitcoin employs a stack-based language where data items are layered one atop another. Operations occur by removing and manipulating the top stack item, with outcomes being returned to the stack.
When a script is executed and verified, it comprises two main components: the "witness" script, which unlocks the funds, and the locking script attached to the transaction output. During execution, the witness script is initially placed to the left of the locking script. The execution progresses from left to right, with each element processed sequentially. Consider the following simple example:
1 2 | OP_ADD 3 OP_EQUALIn this script, the number 1 lands on the stack first, topped by 2. OP_ADD then adds these numbers, leaving the result, 3, on the stack. When another 3 is added, OP_EQUAL checks if the top two numbers match, returning a 1 (indicating true) or 0 (false) to the stack.
For a script to be successful, it must conclude with a truth value atop the stack; if not, the script (and the transaction) fails, being deemed invalid by consensus.
Let’s now turn to a classic pay-to-pubkey-hash (P2PKH) script, typical for Bitcoin addresses starting with "1":
| DUP HASH160 EQUALVERIFY CHECKSIGInitially, both a signature and a public key are pushed onto the stack. The DUP command then replicates the top stack item, returning it to the top. Hashing the public key duplicate with HASH160 places its hash back on the stack. EQUALVERIFY checks and confirms the equality of the top two items, but it does more: it removes the top stack entry if false, thus invalidating the transaction. Finally, CHECKSIG verifies the signature against the transaction’s hash using the top stack items: the signature and public key.
Now, let’s explore the intricacies of CSFS.
Understanding CSFS
One of the most vital opcodes in Bitcoin is CHECKSIG. It’s almost ubiquitous in transactions for signature verification. However, CHECKSIG’s limitation is its insistence on verifying signatures solely against the transaction itself.
Enter CSFS: this new opcode permits signature verification against any chosen message placed directly on the stack, diversifying the scope beyond mere transaction-bound verifications. The operational process is quite straightforward:
| CSFSThe stack is loaded with a signature and message, followed by a public key. CSFS then assesses the top three items as public key, message, and signature—verifying the signature against the message. A valid check places a 1 on the stack.
And that’s it: a simplified CHECKSIG version for flexible message verification beyond the standard spending transaction.
Practical Applications of CSFS
Why verify a signature against a random stack message rather than a transaction? Here’s where CSFS shows its mettle:
-
Floating Signatures for Lightning: Collaborating with CTV, CSFS can emulate a long-anticipated Lightning feature: floating signatures, adaptable to various transactions. This concept was initially aired as a new sighash flag for signature application. It holds potential for bypassing channel penalties, thus refining channel security by sidestepping unauthorized fund claims.
-
Delegating UTXO Control: CSFS enables off-chain UTXO control delegation. By designing scripts that allow CSFS key-approved public keys to pass through traditional CHECKSIG screening, anyone’s spending authority can be delegated sans movement on-chain.
- Advanced Introspection with CAT: By combining with CAT, CSFS helps in creating intricate introspection functionalities. It’s worth noting that although CSFS might not be indispensable for such advancements, the pairing with CAT amplifies capability.
Final Thoughts
CSFS, while straightforward, pairs effortlessly with covenant opcodes to augment Bitcoin’s functionality. Although highlighted in the context of Lightning Network’s floating signatures, its utility extends across any Bitcoin-based protocol working with pre-signed transactions.
Beyond floating signatures, script delegation presents a flexible paradigm that transcends mere public key control, accommodating dynamic inclusions like timelock and hashlock values. Variables once hardcoded into scripts can now be applied adaptively, thanks to CSFS.
Since its introduction, CSFS has matured significantly, with active deployments on the Liquid Network and Bitcoin Cash since 2016 and 2018, respectively. With its broad utility spectrum and robust history, CSFS stands out as a compelling addition to the Bitcoin scripting landscape, promising nuanced and expansive applications.
