This is the second article in one series Deep diving in individual covenant proposals that have reached a maturity point that deserves an in -depth breakdown.
Checksigfromstack (CSFS), made by Brandon Black and Jeremy Rubin with BIP 348, is not a pact. As I said in the introductory article to this series, some of the suggestions I would cover are not pacts, but synergies or among themselves with them in some way. CSFS is the first example of that.
CSFS is a very simple opcode, but before we go through how it works, let’s look at the basics of how a Bitcoin script actually works.
Script is a stack -based language. This means that data is “stacked” together on top of each other on the stack and operated further by removing a product from the top of the stack to work based on what an OPCODE does, either returning the data or a result from it to the top of the stack.
There are two parts of a script when eventually performed and verified, “witness” that are delivered to unlock the script and the script included in the output used. The witness/unlocking script “added” to the left side of the locking script, and then each element is added to (or operating) the stack one by one left to the right. Look at this example (“|“Marks the boundary between the witness and the manuscript):
1 2 | OP_ADD 3 OP_EQUAL
This example script adds the value “1” to the stack, then the value “2” on top of it. Op_add takes the top two elements of the stack and adds them together and puts the result back on the stack (so now everything is on the stack, “3”). Another “3” is then added to the stack. The last item, Op_equal, takes the top two items in the stack and returns a “1” to the stack (1 and 0 can represent sand or false as well as numbers).
A script should conclude that the last item on top of the stack is true, otherwise the script (and transaction execution of it) fails and considered agreement invalid.
This is a basic example of a pay-to-pubkey hash (P2PKH) script, ie. The inheritance addresses that start with a “1”:
First, the signature and the public key are added to the stack. Then is called the DUP, which takes the top poor element and duplicates it and returns it to the top of the stack. Hash160 takes the top poor element (the public keyplicate), hash it and then returns it to the top of the stack. The public keyhash from the script is put on top of the stack. Equalverify works the same as straight, it grabs the top two stack items and returns a 1 or 0 based on the result. The only difference is Equalverify, which also runs verification according to equal, which fails the transaction if the top poor element is not 1 and also removes the top poor element. Finally, Checksig is run, grabbing the top two stack elements, assuming they are a signature and a pubkey, and verify the signature implicitly against the hash of the transaction that is verified. If it is valid, it puts a 1 on top of the stack.
How CSFS works
Checksig is one of the most commonly used opcodes in Bitcoin. Each transaction, with almost no exceptions, uses this up at one point in one of its scripts. Signature verification is a basic component of the Bitcoin protocol. The problem is that there is hardly no flexibility as to what message you check the signature against. Checksig will only verify a signature against the transaction verified. There is some flexibility, ie. That you can decide with some degree of freedom which parts of the transaction signature apply, but it is.
CSFS aims to change this by allowing a signature to be verified against any arbitrary message pushed directly on the stack, rather than being limited to verification of signatures against the transaction itself. The Opcode follows a very basic operational structure:
The signature and message fall on top of the stack, then the public key on top of them, and eventually CSFS grabs the top three items from the stack, provided they are the public key, message and signature from top to bottom, confirming the signature against the message. If the signature is valid, a 1 is placed on the stack.
That’s it. A simple variant of controls that allows users to specify arbitrary messages instead of only the consumption transaction.
What are CSFs useful for
So what exactly is that good for? What is the use of checking a signature against any message on the stack instead of against the expense transaction?
First, in combination with CTV, it can provide a functionality that corresponds to something that Lightning developers have wanted from the very beginning, fluid signatures that can associate with different transactions. This was originally suggested as a new Sighash flag for signatures (the field that dictates which parts of a transaction a signature applies to). This was necessary because a transaction signature covers the transaction IID for the transaction that created output used. This means that a signature is only valid for a transaction using it accurate production.
This is a desired behavior for lightning because it would allow us to remove itself with channel penalties. Each previous lightning reduction needs a penalty key and transaction to make sure your channel’s counterparty never uses any of them to try to demand funds they don’t own. If they try, you can claim all their money. A superior functionality would be something that allows you to simply “attach” the current state transaction to anyone earlier to stop the theft attempt by distributing funds properly as opposed to confiscating them.
This can be achieved with a basic script that takes a CTV -HASH and a signature over it controlled using CSFS. This would give any transaction hash signed by the CSFS key to use any output created with this script.
Another useful feature is the delegation of control of a UTXO. Just as any CTV -HASH signed by a CSFS key can validly use a UTXO with a script designed for it, other variables can be transferred to the script to be checked, such as a new public key. A script could be constructed that gives a CSFS key to log on to any Public key, which could then be validated using CSFs and used for a normal control of validation. This allows you to delegate the opportunity to use an UTXO for anyone else without having to move it on the chain.
Finally, in combination with CAT, CSFs can be used to compose much more complex introspection functionality. However, as we see later in the series, CSFs are actually not required to emulate any of this more advanced behavior as Cat is only capable of it.
Closing thoughts
CSFS is a very basic upset that, in addition to offering simple useful functionality in its own right, composes very nicely with even the simplest covenants opcodes to create very useful functionality. While the example above for fluid signatures specifically refers to Lightning Network, liquid signatures are a generally useful primitive that applies to any protocol built on Bitcoin using pre -empted transactions.
In addition to fluid signatures, the script delegation is a very useful primitive that generalizes far beyond delegating control over a UTXO to a new public key. The same basic ability to “sideload” variables after the fact in a script validation current can apply to everything, not just public keys. Tidelock values, hashlock -fimages, etc. Any script that hardcodes, a variable to verify against, can now have these values dynamically added after the fact.
In addition, CSFS is a very mature suggestion. It has an implementation that has been live on the floating network and elements (Codebase Liquid User) since 2016. In addition, Bitcoin Cash has had a version of it since 2018.
CSFS is a very mature suggestion that conceptually goes back almost as long as I have been in this room, with several mature implementations and very clear use cases it can be used for.