1005 Alcyon Dr Bellmawr NJ 08031
+1 484-446-2566
support@bmcpros.com
This is the second article series Deeply studying the various covenant proposals, which have reached maturity and deserve deep collapse.
Brandon Black and Jeremy Rubin’s CheckSigFromStack (CSF) proposed by Bip 348 is not a covenant. As I said in this introductory series, some of the suggestions I want to cover are not covenants, but are somehow collaborative or relating to them. CSF is the first example.
CSFS is a very simple opcode, but before we take a closer look at how it works, let’s take a look at the basics of how bitcoin scripts actually work.
Scripting is a stack-based language. This means that the data is “stacked” on the stack and operates by deleting the items from the top of the stack to follow what OpCode does to return data or return data from the data result to the top of the stack.
When the script is finally executed and verified, there are two parts, providing the “witness” to unlock the script, and the script included in the output spent. The witness/unlock script is “added” to the left of the lock script and then adds each element to (or operates) the stack one or more. View this example (“|Marking the boundary between witnesses and script):
1 2 | ON_ADD 3 ON_EQUAL
This sample script adds the value “1” to the stack and adds the value “2” there. OP_ADD adds the first two elements of the stack together and adds the result to the stack (so, everything on the stack is now “3”). Then add another “3” to the stack. The last item, op_equal, brings the first two items of the stack to the stack (1 and 0 represent true or error and numbers).
The script must be true with the last item at the top of the stack, otherwise the script (and the transaction that executes it) fails and the consensus is considered invalid.
Here is a basic example of a paid-Pakki Hash (P2PKH) script, a legacy address starting with “1”:
First, the signature and public key are added to the stack. Then called a DUP, the dup takes up the top stack item and copies it, then returns it to the top of the stack. HASH160 takes a top stack project (public key copy), hash it, and then returns it to the top of the stack. The script’s public key hash is placed on top of the stack. The equality function is the same as the equality function, it grabs two top stack items and returns 1 or 0 based on the result. The only difference is that the equal value can also be run after the equal value, if the top stack item is not 1, the transaction will fail and the top stack item is also removed. Finally running the check, which grabs the first two stack items, assuming they are signed and public, and implicitly verifies the signature to verify the hash of the verified transaction. If it works, place 1 on top of the stack.
How CSF works
CheckSig is one of the most commonly used Opcodes in Bitcoin. Every transaction has almost no exception, using this opcode at some point in one of its scripts. Signature verification is a fundamental part of the Bitcoin protocol. The problem is that you are checking the signature information with little flexibility. CheckSig can only verify signatures and transactions being verified. There is some flexibility, i.e. you can some extent decide which parts of the transaction in which the signature applies, but that’s all.
The purpose of CSF is to change this by allowing any arbitrary message to push the signature directly to the stack, rather than being limited to signature verification of the transaction itself. OpCode follows a very basic operating structure:
The signature and message are placed on the top of the stack, and then the public keys are placed on the top of them, and finally the CSF grabs the first three items from the stack, assuming they are public keys, messages and signatures from top to bottom, thus verifying the signature for the message. If the signature is valid, place 1 on the stack.
That’s it. A simple checksig variant that allows users to specify arbitrary messages, not just spend transactions.
What CSF pair
So what is this? What is the purpose of checking signatures using arbitrary messages on the stack instead of any messages that are transactions with spending?
First, in conjunction with CTV, it can provide the equivalent of a lightning developer’s desire from the start, connecting to floating signatures for different transactions. This was originally proposed as a new Sighash logo for the signature (the field that determines the transaction part that the signature applies). This is needed because the transaction signature covers the transaction ID of the transaction that is spent to create the output. This means that the signature is only valid for transaction expenditure Accurate Output.
This is the ideal behavior of lightning because it eliminates channel penalties. Every lightning state in the past required a fine key and a transaction to ensure that your channel counterpart never uses any of them to try to ask for funds they don’t own. If they try, you can ask for all their money. Excellent features will allow you to simply “attach” current state transactions to any previous transactions to prevent theft attempts by correctly allocating funds rather than forfeiting them.
This can be done with a basic script that requires a signature checked using a CTV hash and a CSF. This will allow any transaction hash signed by that CSFS key to spend any output created using this script.
Another useful feature is control over UTXO. The same way as any CTV hash signed by a CSFS key can effectively spend UTXO using the script designed for this, and other variables can be passed into the script for inspection, such as a new public key. Scripts can be constructed to allow CSFS keys to be any The public key can then be verified using CSF and used for normal check verification. This will allow you to spend UTXO on anyone else’s ability without moving it on the chain.
Finally, in conjunction with CAT, CSF can be used to constitute more complex introspection functions. As we will see later in the series, there is really no need for CSF to mimic any more advanced behavior, as CAT alone can do so.
End thought
CSFS is a very basic OpCode that, in addition to providing simple and useful features, even the simplest Covenant Opcodes can create very useful features well. While the above examples about floating signatures refer specifically to the Lightning Network, floating signatures are a generally useful original symbol for any protocol built with pre-signed transactions.
Apart from floating signatures, script delegations are a very useful primitive nature that will go far beyond delegating control of UTXO with the new public key. After the fact-verification flows into the script verification stream, the basic ability of the “local load” variable can also apply to anything, not just a common key. timelock value, hashlock pre-image, etc. Any script for hard codes to verify variables can now dynamically add these values after facts.
Most importantly, CSF is a very mature suggestion. It has implementations that have been on liquid networks and elements (code library liquid uses) since 2016. Additionally, Bitcoin Cash has had its version since 2018.
CSF is a very mature suggestion that almost goes back conceptually to me in this space, with multiple mature implementations and can be applied to very clear use cases.