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
