That is the second article in a sequence deep diving into particular person covenant proposals which have reached some extent of maturity meriting an in-depth breakdown.
CHECKSIGFROMSTACK (CSFS), put ahead by Brandon Black and Jeremy Rubin with BIP 348, will not be a covenant. As I mentioned within the introductory article to this sequence, a number of the proposals I’d be protecting aren’t covenants, however synergize or interrelate with them in a roundabout way. CSFS is the primary instance of that.
CSFS is a quite simple opcode, however earlier than we undergo the way it works let’s have a look at the fundamentals of how a Bitcoin script truly works.
Script is a stack primarily based language. That signifies that knowledge is “stacked” collectively on prime of one another on the stack, and operated on by eradicating an merchandise from the highest of the stack to function on primarily based on what an opcode does, both returning the info or a consequence from it to the highest of the stack.
There are two elements of a script when it’s finally executed and verified, the “witness” supplied to unlock the script, and the script included within the output being spent. The witness/unlocking script is “added” to the left facet of the locking script, after which every factor is added to (or operates on) the stack one after the other left to proper. Have a look at this instance (the “|” marks the boundary between the witness and script):
1 2 | OP_ADD 3 OP_EQUAL
This instance script provides the worth “1” to the stack, then the worth “2” on prime of that. OP_ADD takes the highest two parts of the stack and provides them collectively, placing the consequence again on to the stack (so now all that’s on the stack is “3”). One other “3” is then added to the stack. The final merchandise, OP_EQUAL, takes the highest two gadgets of the stack and returns a “1” to the stack (1 and 0 can characterize True or False in addition to numbers).
A script should finish with the final merchandise on the highest of the stack being True, in any other case the script (and transaction executing it) fails and is taken into account consensus invalid.
It is a fundamental instance of a pay-to-pubkey-hash (P2PKH) script, i.e. the legacy addresses that begin with a “1”:
First the signature and the general public key are added to the stack. Then DUP is named, which takes the highest stack merchandise and duplicates it, returning it to the highest of the stack. HASH160 takes the highest stack merchandise (the general public key duplicate), hashes it, then returns it to the highest of the stack. The general public key hash from the script is placed on prime of the stack. EQUALVERIFY capabilities the identical as EQUAL, it grabs the 2 prime stack gadgets and returns a 1 or 0 primarily based on the end result. The one distinction is EQUALVERIFY additionally runs VERIFY after EQUAL, which fails the transaction if the highest stack merchandise will not be 1, and likewise removes the highest stack merchandise. Lastly CHECKSIG is run, which grabs the highest two stack gadgets assuming them to be a signature and a pubkey, and verifies the signature implicitly in opposition to the hash of the transaction being verified. Whether it is legitimate it places a 1 on prime of the stack.
How CSFS Works
CHECKSIG is likely one of the most used opcodes in Bitcoin. Each transaction, with nearly no exceptions, makes use of this opcode in some unspecified time in the future in considered one of its scripts. Signature verification is a foundational part of the Bitcoin protocol. The issue is, there’s nearly no flexibility when it comes to what message you’re checking the signature in opposition to. CHECKSIG will solely confirm a signature in opposition to the transaction being verified. There’s some flexibility, i.e. you possibly can resolve with a point of freedom what elements of the transaction the signature applies to, however that’s it.
CSFS goals to vary this by permitting a signature to be verified in opposition to any arbitrary message that’s pushed straight onto the stack, as an alternative of being restricted to the verification of signatures in opposition to the transaction itself. The opcode follows a really fundamental operational construction:
The signature and message are dropped on prime of the stack, then the general public key on prime of them, and eventually CSFS grabs the highest three gadgets from the stack assuming them to be the general public key, message, and signature from prime to backside, verifying the signature in opposition to the message. If the signature is legitimate, a 1 is positioned on the stack.
That’s it. A easy variant of CHECKSIG that lets customers specify arbitrary messages as an alternative of simply the spending transaction.
What Is CSFS Helpful For
So what precisely is that this good for? What’s using checking a signature in opposition to an arbitrary message on the stack as an alternative of in opposition to the spending transaction?
Firstly, together with CTV it might probably present a performance equal to one thing that Lightning builders have needed because the very starting, floating signatures that may connect to completely different transactions. This was initially proposed as a brand new sighash flag for signatures (the sector that dictates what elements of a transaction a signature applies to). This was wanted as a result of a transaction signature covers the transaction ID of the transaction that created the output being spent. This implies a signature is just legitimate for a transaction spending that precise output.
It is a desired habits for Lightning as a result of it might enable us to dispose of channel penalties. Each previous Lightning state wants a penalty key and transaction with a view to be certain that your channel counterparty by no means makes use of any of them to attempt to declare funds they don’t personal. If they fight you possibly can declare all their cash. A superior performance can be one thing that lets you merely “connect” the present state transaction to any earlier one to cease the theft try by distributing funds accurately versus confiscating them.
This may be achieved with a fundamental script that takes a CTV hash and a signature over it that’s checked utilizing CSFS. This could enable any transaction hash signed by that CSFS key to spend any output that’s created with this script.
One other helpful function is delegation of management of a UTXO. The identical method that any CTV hash signed by a CSFS key can validly spend a UTXO with a script designed for that, different variables may be handed into the script to be checked in opposition to, reminiscent of a brand new public key. A script may very well be constructed that permits a CSFS key to log off on any public key, which then may very well be validated utilizing CSFS and used for a traditional CHECKSIG validation. This could mean you can delegate the flexibility to spend a UTXO to anybody else with out having to maneuver it on-chain.
Lastly, together with CAT, CSFS can be utilized to compose far more advanced introspection performance. As we are going to see later within the sequence although, CSFS will not be truly required to emulate any of this extra superior habits, as CAT alone is ready to take action.
Closing Ideas
CSFS is a really fundamental opcode that along with providing easy helpful performance in its personal proper composes very properly with even the most straightforward covenant opcodes to create very helpful performance. Whereas the instance above relating to floating signatures particularly references the Lightning Community, floating signatures are a typically helpful primitive which can be relevant to any protocol constructed on Bitcoin making use of pre-signed transactions.
Along with floating signatures, script delegation is a really helpful primitive that generalizes far past delegating management over a UTXO to a brand new public key. The identical fundamental capability to “sideload” variables after the very fact right into a script validation circulate can apply to something, not simply public keys. Timelock values, hashlock preimages, and so forth. Any script that hardcodes a variable to confirm in opposition to can now have these values dynamically added after the very fact.
On prime of that, CSFS is a really mature proposal. It has an implementation that has been dwell on the Liquid Community and Parts (the codebase Liquid makes use of) since 2016. As well as Bitcoin Money has had a model of it since 2018.
CSFS is a really mature proposal that goes again conceptually nearly so long as I’ve been on this area, with a number of mature implementations, and really clear use circumstances it may be utilized to.
That is the second article in a sequence deep diving into particular person covenant proposals which have reached some extent of maturity meriting an in-depth breakdown.
CHECKSIGFROMSTACK (CSFS), put ahead by Brandon Black and Jeremy Rubin with BIP 348, will not be a covenant. As I mentioned within the introductory article to this sequence, a number of the proposals I’d be protecting aren’t covenants, however synergize or interrelate with them in a roundabout way. CSFS is the primary instance of that.
CSFS is a quite simple opcode, however earlier than we undergo the way it works let’s have a look at the fundamentals of how a Bitcoin script truly works.
Script is a stack primarily based language. That signifies that knowledge is “stacked” collectively on prime of one another on the stack, and operated on by eradicating an merchandise from the highest of the stack to function on primarily based on what an opcode does, both returning the info or a consequence from it to the highest of the stack.
There are two elements of a script when it’s finally executed and verified, the “witness” supplied to unlock the script, and the script included within the output being spent. The witness/unlocking script is “added” to the left facet of the locking script, after which every factor is added to (or operates on) the stack one after the other left to proper. Have a look at this instance (the “|” marks the boundary between the witness and script):
1 2 | OP_ADD 3 OP_EQUAL
This instance script provides the worth “1” to the stack, then the worth “2” on prime of that. OP_ADD takes the highest two parts of the stack and provides them collectively, placing the consequence again on to the stack (so now all that’s on the stack is “3”). One other “3” is then added to the stack. The final merchandise, OP_EQUAL, takes the highest two gadgets of the stack and returns a “1” to the stack (1 and 0 can characterize True or False in addition to numbers).
A script should finish with the final merchandise on the highest of the stack being True, in any other case the script (and transaction executing it) fails and is taken into account consensus invalid.
It is a fundamental instance of a pay-to-pubkey-hash (P2PKH) script, i.e. the legacy addresses that begin with a “1”:
First the signature and the general public key are added to the stack. Then DUP is named, which takes the highest stack merchandise and duplicates it, returning it to the highest of the stack. HASH160 takes the highest stack merchandise (the general public key duplicate), hashes it, then returns it to the highest of the stack. The general public key hash from the script is placed on prime of the stack. EQUALVERIFY capabilities the identical as EQUAL, it grabs the 2 prime stack gadgets and returns a 1 or 0 primarily based on the end result. The one distinction is EQUALVERIFY additionally runs VERIFY after EQUAL, which fails the transaction if the highest stack merchandise will not be 1, and likewise removes the highest stack merchandise. Lastly CHECKSIG is run, which grabs the highest two stack gadgets assuming them to be a signature and a pubkey, and verifies the signature implicitly in opposition to the hash of the transaction being verified. Whether it is legitimate it places a 1 on prime of the stack.
How CSFS Works
CHECKSIG is likely one of the most used opcodes in Bitcoin. Each transaction, with nearly no exceptions, makes use of this opcode in some unspecified time in the future in considered one of its scripts. Signature verification is a foundational part of the Bitcoin protocol. The issue is, there’s nearly no flexibility when it comes to what message you’re checking the signature in opposition to. CHECKSIG will solely confirm a signature in opposition to the transaction being verified. There’s some flexibility, i.e. you possibly can resolve with a point of freedom what elements of the transaction the signature applies to, however that’s it.
CSFS goals to vary this by permitting a signature to be verified in opposition to any arbitrary message that’s pushed straight onto the stack, as an alternative of being restricted to the verification of signatures in opposition to the transaction itself. The opcode follows a really fundamental operational construction:
The signature and message are dropped on prime of the stack, then the general public key on prime of them, and eventually CSFS grabs the highest three gadgets from the stack assuming them to be the general public key, message, and signature from prime to backside, verifying the signature in opposition to the message. If the signature is legitimate, a 1 is positioned on the stack.
That’s it. A easy variant of CHECKSIG that lets customers specify arbitrary messages as an alternative of simply the spending transaction.
What Is CSFS Helpful For
So what precisely is that this good for? What’s using checking a signature in opposition to an arbitrary message on the stack as an alternative of in opposition to the spending transaction?
Firstly, together with CTV it might probably present a performance equal to one thing that Lightning builders have needed because the very starting, floating signatures that may connect to completely different transactions. This was initially proposed as a brand new sighash flag for signatures (the sector that dictates what elements of a transaction a signature applies to). This was wanted as a result of a transaction signature covers the transaction ID of the transaction that created the output being spent. This implies a signature is just legitimate for a transaction spending that precise output.
It is a desired habits for Lightning as a result of it might enable us to dispose of channel penalties. Each previous Lightning state wants a penalty key and transaction with a view to be certain that your channel counterparty by no means makes use of any of them to attempt to declare funds they don’t personal. If they fight you possibly can declare all their cash. A superior performance can be one thing that lets you merely “connect” the present state transaction to any earlier one to cease the theft try by distributing funds accurately versus confiscating them.
This may be achieved with a fundamental script that takes a CTV hash and a signature over it that’s checked utilizing CSFS. This could enable any transaction hash signed by that CSFS key to spend any output that’s created with this script.
One other helpful function is delegation of management of a UTXO. The identical method that any CTV hash signed by a CSFS key can validly spend a UTXO with a script designed for that, different variables may be handed into the script to be checked in opposition to, reminiscent of a brand new public key. A script may very well be constructed that permits a CSFS key to log off on any public key, which then may very well be validated utilizing CSFS and used for a traditional CHECKSIG validation. This could mean you can delegate the flexibility to spend a UTXO to anybody else with out having to maneuver it on-chain.
Lastly, together with CAT, CSFS can be utilized to compose far more advanced introspection performance. As we are going to see later within the sequence although, CSFS will not be truly required to emulate any of this extra superior habits, as CAT alone is ready to take action.
Closing Ideas
CSFS is a really fundamental opcode that along with providing easy helpful performance in its personal proper composes very properly with even the most straightforward covenant opcodes to create very helpful performance. Whereas the instance above relating to floating signatures particularly references the Lightning Community, floating signatures are a typically helpful primitive which can be relevant to any protocol constructed on Bitcoin making use of pre-signed transactions.
Along with floating signatures, script delegation is a really helpful primitive that generalizes far past delegating management over a UTXO to a brand new public key. The identical fundamental capability to “sideload” variables after the very fact right into a script validation circulate can apply to something, not simply public keys. Timelock values, hashlock preimages, and so forth. Any script that hardcodes a variable to confirm in opposition to can now have these values dynamically added after the very fact.
On prime of that, CSFS is a really mature proposal. It has an implementation that has been dwell on the Liquid Community and Parts (the codebase Liquid makes use of) since 2016. As well as Bitcoin Money has had a model of it since 2018.
CSFS is a really mature proposal that goes again conceptually nearly so long as I’ve been on this area, with a number of mature implementations, and really clear use circumstances it may be utilized to.
