Bitcoin Magazine
Bitcoin Covenants: CHECKSIGFROMSTACK (BIP 348)
This is the second article in a series deep diving into individual covenant proposals that have reached a point of maturity meriting an in-depth breakdown.
CHECKSIGFROMSTACK (CSFS), put forward by Brandon Black and Jeremy Rubin with BIP 348, is not a covenant. As I said in the introductory article to this series, some of the proposals I would be covering are not covenants, but synergize or interrelate 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. That means that data is “stacked” together on top of each other on the stack, and operated on by removing an item from the top of the stack to operate on 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 it is ultimately executed and verified, the “witness” provided to unlock the script, and the script included in the output being spent. The witness/unlocking script is “added” to the left side of the locking script, and then each element is added to (or operates on) the stack one by one left to right. Look at this example (the “|” marks the boundary between the witness and script):
1 2 | OP_ADD 3 OP_EQUAL
This example script adds the value “1” to the stack, then the value “2” on top of that. OP_ADD takes the top two elements of the stack and adds them together, putting the result back on to the stack (so now all that is on the stack is “3”). Another “3” is then added to the stack. The last item, OP_EQUAL, takes the top two items of the stack and returns a “1” to the stack (1 and 0 can represent True or False as well as numbers).
A script must end with the last item on the top of the stack being True, otherwise the script (and transaction executing it) fails and is considered consensus invalid.
This is a basic example of a pay-to-pubkey-hash (P2PKH) script, i.e. the legacy addresses that start with a “1”:
<signature> <pubkey> | DUP HASH160 <pubkey-hash> EQUALVERIFY CHECKSIG
First the signature and the public key are added to the stack. Then DUP is called, which takes the top stack item and duplicates it, returning it to the top of the stack. HASH160 takes the top stack item (the public key duplicate), hashes it, then returns it to the top of the stack. The public key hash from the script is put on top of the stack. EQUALVERIFY functions the same as EQUAL, it grabs the two top stack items and returns a 1 or 0 based on the outcome. The only difference is EQUALVERIFY also runs VERIFY after EQUAL, which fails the transaction if the top stack item is not 1, and also removes the top stack item. Finally CHECKSIG is run, which grabs the top two stack items assuming them to be a signature and a pubkey, and verifies the signature implicitly against the hash of the transaction being verified. If it is valid it puts a 1 on top of the stack.
CHECKSIG is one of the most used opcodes in Bitcoin. Every transaction, with almost no exceptions, makes use of this opcode at some point in one of its scripts. Signature verification is a foundational component of the Bitcoin protocol. The problem is, there is almost no flexibility in terms of what message you are checking the signature against. CHECKSIG will only verify a signature against the transaction being verified. There is some flexibility, i.e. you can decide with some degree of freedom what parts of the transaction the signature applies to, but that’s it.
CSFS aims to change this by allowing a signature to be verified against any arbitrary message that is pushed directly onto the stack, instead of being limited to the verification of signatures against the transaction itself. The opcode follows a very basic operational structure:
<signature> <message> | <pubkey> CSFS
The signature and message are dropped on top of the stack, then the public key on top of them, and finally CSFS grabs the top three items from the stack assuming them to be the public key, message, and signature from top to bottom, verifying the signature against the message. If the signature is valid, a 1 is placed on the stack.
That’s it. A simple variant of CHECKSIG that lets users specify arbitrary messages instead of just the spending transaction.
So what exactly is this good for? What is the use of checking a signature against an arbitrary message on the stack instead of against the spending transaction?
Firstly, in combination with CTV it can provide a functionality equivalent to something that Lightning developers have wanted since the very beginning, floating signatures that can attach to different transactions. This was originally proposed as a new sighash flag for signatures (the field that dictates what parts of a transaction a signature applies to). This was needed because a transaction signature covers the transaction ID of the transaction that created the output being spent. This means a signature is only valid for a transaction spending that exact output.
This is a desired behavior for Lightning because it would allow us to do away with channel penalties. Every past Lightning state needs a penalty key and transaction in order to ensure that your channel counterparty never uses any of them to try to claim 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 any previous one to stop the theft attempt by distributing funds correctly as opposed to confiscating them.
This can be accomplished with a basic script that takes a CTV hash and a signature over it that is checked using CSFS. This would allow any transaction hash signed by that CSFS key to spend any output that is created with this script.
Another useful feature is delegation of control of a UTXO. The same way that any CTV hash signed by a CSFS key can validly spend a UTXO with a script designed for that, other variables can be passed into the script to be checked against, such as a new public key. A script could be constructed that allows a CSFS key to sign off on any public key, which then could be validated using CSFS and used for a normal CHECKSIG validation. This would allow you to delegate the ability to spend a UTXO to anyone else without having to move it on-chain.
Lastly, in combination with CAT, CSFS can be used to compose much more complex introspection functionality. As we will see later in the series though, CSFS is not actually required to emulate any of this more advanced behavior, as CAT alone is able to do so.
CSFS is a very basic opcode that in addition to offering simple useful functionality in its own right composes very nicely with even the most simple covenant opcodes to create very useful functionality. While the example above regarding floating signatures specifically references the Lightning Network, floating signatures are a generally useful primitive that are applicable to any protocol built on Bitcoin making use of pre-signed transactions.
In addition to floating signatures, 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 into a script validation flow can apply to anything, not just public keys. Timelock values, hashlock preimages, etc. Any script that hardcodes a variable to verify against can now have those values dynamically added after the fact.
On top of that, CSFS is a very mature proposal. It has an implementation that has been live on the Liquid Network and Elements (the codebase Liquid uses) since 2016. In addition Bitcoin Cash has had a version of it 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 use cases it can be applied to.
This post Bitcoin Covenants: CHECKSIGFROMSTACK (BIP 348) first appeared on Bitcoin Magazine and is written by Shinobi.
Full story here:
Bitcoin Covenants: CHECKSIGFROMSTACK (BIP 348)
This is the second article in a series deep diving into individual covenant proposals that have reached a point of maturity meriting an in-depth breakdown.
CHECKSIGFROMSTACK (CSFS), put forward by Brandon Black and Jeremy Rubin with BIP 348, is not a covenant. As I said in the introductory article to this series, some of the proposals I would be covering are not covenants, but synergize or interrelate 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. That means that data is “stacked” together on top of each other on the stack, and operated on by removing an item from the top of the stack to operate on 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 it is ultimately executed and verified, the “witness” provided to unlock the script, and the script included in the output being spent. The witness/unlocking script is “added” to the left side of the locking script, and then each element is added to (or operates on) the stack one by one left to right. Look at this example (the “|” marks the boundary between the witness and script):
1 2 | OP_ADD 3 OP_EQUAL
This example script adds the value “1” to the stack, then the value “2” on top of that. OP_ADD takes the top two elements of the stack and adds them together, putting the result back on to the stack (so now all that is on the stack is “3”). Another “3” is then added to the stack. The last item, OP_EQUAL, takes the top two items of the stack and returns a “1” to the stack (1 and 0 can represent True or False as well as numbers).
A script must end with the last item on the top of the stack being True, otherwise the script (and transaction executing it) fails and is considered consensus invalid.
This is a basic example of a pay-to-pubkey-hash (P2PKH) script, i.e. the legacy addresses that start with a “1”:
<signature> <pubkey> | DUP HASH160 <pubkey-hash> EQUALVERIFY CHECKSIG
First the signature and the public key are added to the stack. Then DUP is called, which takes the top stack item and duplicates it, returning it to the top of the stack. HASH160 takes the top stack item (the public key duplicate), hashes it, then returns it to the top of the stack. The public key hash from the script is put on top of the stack. EQUALVERIFY functions the same as EQUAL, it grabs the two top stack items and returns a 1 or 0 based on the outcome. The only difference is EQUALVERIFY also runs VERIFY after EQUAL, which fails the transaction if the top stack item is not 1, and also removes the top stack item. Finally CHECKSIG is run, which grabs the top two stack items assuming them to be a signature and a pubkey, and verifies the signature implicitly against the hash of the transaction being verified. If it is valid it puts a 1 on top of the stack.
How CSFS Works
CHECKSIG is one of the most used opcodes in Bitcoin. Every transaction, with almost no exceptions, makes use of this opcode at some point in one of its scripts. Signature verification is a foundational component of the Bitcoin protocol. The problem is, there is almost no flexibility in terms of what message you are checking the signature against. CHECKSIG will only verify a signature against the transaction being verified. There is some flexibility, i.e. you can decide with some degree of freedom what parts of the transaction the signature applies to, but that’s it.
CSFS aims to change this by allowing a signature to be verified against any arbitrary message that is pushed directly onto the stack, instead of being limited to the verification of signatures against the transaction itself. The opcode follows a very basic operational structure:
<signature> <message> | <pubkey> CSFS
The signature and message are dropped on top of the stack, then the public key on top of them, and finally CSFS grabs the top three items from the stack assuming them to be the public key, message, and signature from top to bottom, verifying the signature against the message. If the signature is valid, a 1 is placed on the stack.
That’s it. A simple variant of CHECKSIG that lets users specify arbitrary messages instead of just the spending transaction.
What Is CSFS Useful For
So what exactly is this good for? What is the use of checking a signature against an arbitrary message on the stack instead of against the spending transaction?
Firstly, in combination with CTV it can provide a functionality equivalent to something that Lightning developers have wanted since the very beginning, floating signatures that can attach to different transactions. This was originally proposed as a new sighash flag for signatures (the field that dictates what parts of a transaction a signature applies to). This was needed because a transaction signature covers the transaction ID of the transaction that created the output being spent. This means a signature is only valid for a transaction spending that exact output.
This is a desired behavior for Lightning because it would allow us to do away with channel penalties. Every past Lightning state needs a penalty key and transaction in order to ensure that your channel counterparty never uses any of them to try to claim 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 any previous one to stop the theft attempt by distributing funds correctly as opposed to confiscating them.
This can be accomplished with a basic script that takes a CTV hash and a signature over it that is checked using CSFS. This would allow any transaction hash signed by that CSFS key to spend any output that is created with this script.
Another useful feature is delegation of control of a UTXO. The same way that any CTV hash signed by a CSFS key can validly spend a UTXO with a script designed for that, other variables can be passed into the script to be checked against, such as a new public key. A script could be constructed that allows a CSFS key to sign off on any public key, which then could be validated using CSFS and used for a normal CHECKSIG validation. This would allow you to delegate the ability to spend a UTXO to anyone else without having to move it on-chain.
Lastly, in combination with CAT, CSFS can be used to compose much more complex introspection functionality. As we will see later in the series though, CSFS is not actually required to emulate any of this more advanced behavior, as CAT alone is able to do so.
Closing Thoughts
CSFS is a very basic opcode that in addition to offering simple useful functionality in its own right composes very nicely with even the most simple covenant opcodes to create very useful functionality. While the example above regarding floating signatures specifically references the Lightning Network, floating signatures are a generally useful primitive that are applicable to any protocol built on Bitcoin making use of pre-signed transactions.
In addition to floating signatures, 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 into a script validation flow can apply to anything, not just public keys. Timelock values, hashlock preimages, etc. Any script that hardcodes a variable to verify against can now have those values dynamically added after the fact.
On top of that, CSFS is a very mature proposal. It has an implementation that has been live on the Liquid Network and Elements (the codebase Liquid uses) since 2016. In addition Bitcoin Cash has had a version of it 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 use cases it can be applied to.
This post Bitcoin Covenants: CHECKSIGFROMSTACK (BIP 348) first appeared on Bitcoin Magazine and is written by Shinobi.
Full story here:
![[DK]](/data/avatars/s/57/57999.jpg?1720990206){kind=avatar}
