NEWSLETTER
This is the second article in a series The deep diving in individual pact proposals that have reached a maturity point that deserves a depth breakdown.
<a target="_blank" href="https://github.com/bitcoin/bips/blob/master/bip-0348.md” target=”_blank” rel=”noopener”>Checksigfromstack (CSF), presented by Brandon Black and Jeremy Rubin with BIP 348, is not a pact. As I said in the introductory article of this series, some of the proposals that I would be covering are not agreements, but to synergize or interrelate with them in some way. CSFS is the first example of that.
CSFS is a very simple operation code, but before going through how it works, let's see the basic concepts of how a bitcoin script works.
The script is a pile -based language. That means that the data is “stacked” together on top of each other in the battery, and are operated by eliminating an element of the upper part of the battery to operate depending on what an operating code does, either returning the data or a result of it to the upper part of the battery.
There are two parts of a script when it is finally executed and verified, the “witness” provided to unlock the script, and the script included in the output that is spent. The witness/unlock script is “add” to the left side of the locking script, and then each element is added (or operates) the battery one by one from left to right. Look at this example (“|“Mark the boundary between the witness and the script):
1 2 | ON_ADD 3 ON_EQUAL
This example script adds the “1” value to the battery, then the “2” value in addition to that. Op_add takes the two main elements of the battery and adds them, putting the result again in the pile (so now everything in the battery is “3”). Then another “3” is added to the battery. The last element, op_equal, takes the two main elements of the battery and returns a “1” to the pile (1 and 0 can represent the true and false numbers).
A script must end the last element in the upper part of the pile that is true, otherwise, the script (and the transaction that executes it) fails and is considered an invalid consensus.
This is a basic example of a payment script to Pubkey-Hash (P2PKH), that is, the inherited addresses that begin with a “1”:
| DUP HASH160 Checkectivo Checksig from Malia
First, the firm and the public key are added to the battery. Then it is called DUP, who takes the element of the upper battery and doubles it, returning it to the top of the battery. HASH160 Take the element of the upper battery (the duplicate of the public key), hashes it, then returns it to the upper part of the battery. The hash of the public key of the script is placed at the top of the battery. Equalverify works the same as the same, takes the two elements of upper battery and returns a 1 or 0 depending on the result. The only difference is that Verify is also executed verify after the same, which fails the transaction if the upper battery element is not 1, and also eliminates the element of the upper pile. Finally, Checksig is executed, which takes the two upper stack assuming that they are a signature and a public, and verifies the firm implicitly against the hash of the transaction that is verified. If valid, place a 1 on top of the stack.
How CSFS works
Checksig is one of the most used operation codes in bitcoin. Each transaction, almost without exceptions, makes use of this operation code at some time of one of its scripts. The verification of the firm is a fundamental component of the bitcoin protocol. The problem is that there is almost no flexibility in terms of which message the firm is verifying. Checksig will only verify a firm against the transaction that is being verified. There is some flexibility, that is, it can decide with some degree of freedom to which parts of the transaction the signature is applied, but that is.
CSFS aims to change this by allowing a signature against any arbitrary message to be shown directly to the battery, instead of limiting itself to the verification of signatures against the transaction itself. The operation code follows a very basic operational structure:
| CSFS
The firm and the message are dropped at the top of the battery, then the public key at the top of them, and finally CSF takes the three main elements of the battery assuming that they are the public key, the message and the signature from top to bottom, verifying the firm against the message. If the firm is valid, a 1 in the battery is placed.
That's all. A simple checksig variant that allows users to specify arbitrary messages instead of only spending transaction.
What is CSF useful for?
So why is this good? What is the use of verifying a signature against an arbitrary message in the battery instead of the transaction of expenses?
First, in combination with CTV, it can provide a functionality equivalent to something that Lightning developers have wanted from the beginning, floating firms that can join different transactions. This was originally proposed as a new sighast flag for signatures (the field that dictates to which parts of a transaction a signature is applied). This was necessary because a transaction firm covers the transaction ID of the transaction that created the output that is spent. This means that a firm is only valid for a transaction expense that exact production.
This is a desired behavior for Lightning because it would allow us to eliminate channel penalties. Each past of lightning needs a penalty key and a transaction to ensure that your channel counterpart never uses any of them to try to claim funds they do not possess. If you try, you can claim all your money. Superior functionality would be something that simply allows you to “attach” the current state transaction to anyone before to stop the robbery attempt distributing funds correctly instead of confiscating them.
This can be achieved with a basic script that takes a hash CTV and a firm on it that is verified with CSFS. This would allow any transaction hash signed by that CSFS key to spend any output that is believed with this script.
Another useful feature is the control delegation of a UTXO. In the same way that any CTV hash signed by a CSFA key can validly spend a UTXO with a script designed for that, other variables can be transmitted to the script to verify, as a new public key. A script could be built that allows a CSFS key to start any Public Key, which could then be validated using CSF and used for a validation of normal verification. This would allow you to delegate the ability to spend a UTXO on any other person without having to move it in the chain.
Finally, in combination with CAT, CSF can be used to compose much more complex introspection functionality. However, as we will see later in the series, CSFS is not really required to emulate anything of this more advanced behavior, since Cat Alone can do it.
Closing thoughts
CSFS is a very basic operation code that, in addition to offering simple useful functionality in its own right, composes very well with the simplest pact operating codes to create a very useful functionality. While the previous example with respect to floating firms specifically refers to the Lightning Network, floating firms are a generally useful primitive that are applicable to any bitcoin -based protocol that uses transactions prior to the firm.
In addition to floating firms, the Script delegation is a very useful primitive that generalizes much beyond delegating control over a UTXO to a new public key. The same basic capacity to “turn on” variables again after a script validation flow can be applied to anything, not just public keys. Timelock values, preimage hashlock, etc. Any script that codifies a variable to verify now can have those dynamically added values after the fact.
In addition to that, CSFS is a very mature proposal. It has an implementation that has been live on the network and liquid elements (the Codebase Liquid USA) Since 2016. In addition, bitcoin Cash has had a version of that since 2018.
CSFS is a very mature proposal that goes back conceptually almost as long as I have been in this space, with multiple mature implementations, and very clear cases of use to which it can be applied.
