This is the second article in a series You will dive deep into individual contract proposals that have reached maturity worthy of a detailed breakdown.

The Checksigfromstack (CSFS) proposed by Jeremy Rubin of Brandon Black and Bip 348 is not a contract. As mentioned in the introductory articles in this series, some of the proposals I cover are not contracts, but rather interacting with or interrelated with them in some way. CSFS is the first example.

CSFS is a very simple opcode, but before we look at how it works, let’s take a look at the basics of how Bitcoin script actually works.

Scripting is a stack-based language. This means that data is “stacked” each other on top of the stack, and works by removing items from the top of the stack and acting based on what the opcode does.

A script has two parts when it is finally executed and verified. The “witness” provided to unlock the script, and the scripts contained in the output are used. The witness/unlock script is “added” to the left of the lock script, with each element being added (or manipulated) from left to right, one at a time to the stack. Take a look at this example (“|” marks the boundary between the witness and script):

1 2 | on_add 3 on_equal

The script in this example adds the value “1” to the stack and adds the value “2” above it. OP_ADD takes the top two elements of the stack, adds them together, and brings the result back to the stack (so that’s what you’re in the stack is “3”). Then another “3” is added to the stack. The last item, OP_Equal, takes the top two items of the stack and returns “1” to the stack (1 and 0 represent True or false as numbers).

The script must have the last item at the top of the stack terminated with true. Otherwise, the script (and the transaction that runs it) will fail and the consensus is considered invalid.

This is a basic example of a Pay-to-Pubkey-Hash (P2PKH) script. In other words, legacy addresses starting with “1”.

| dup hash160 equerverify checksig

First, the signature and public key are added to the stack. Then the DUP is called to take the top stack item, duplicate it and return it to the top of the stack. Hash160 takes a top stack item (a copy of the public key), hash it, then returns it to the top of the stack. A hash of the public key from the script is placed on top of the stack. eqerverify is the same function as equals, grabs two top stack items and returns either 1 or 0 based on the result. The only difference is that it is also performed to verify after equalverify is equal. This will fail the transaction if the top stack item is not 1 and will also delete the top stack item. Finally, Checksig is run. This implicitly validates the signature against the hash of the transaction being verified, assuming that the top two stack items are signatures and PubKeys. If enabled, place 1 on the stack.

How CSFS works

Checksig is one of the most used opcodes in Bitcoin. All transactions use this opcode at some point in this script, with few exceptions. Signature verification is the fundamental component of the Bitcoin protocol. The problem is that there is little flexibility in terms of messages checking signatures. Checksig only checks signatures for transactions that are being verified. There is some flexibility. This means you have some freedom to decide which part of the transaction the signature applies to, but that’s it.

Rather than being limited to verifying signatures on the transaction itself, CSFS aims to change this by allowing signatures to be verified against any message that is pushed directly to the stack. The opcode follows a very basic operating structure.

| CSFS

Signatures and messages are dropped on top of the stack and published on top of it, and eventually CSFS grabs the top three items from the stack, assuming they are top to bottom public key, message and signatures, and confirms the signatures for the message. If the signature is valid, 1 is placed on the stack.

that’s it. A simple variant of Checksig that allows users to specify arbitrary messages rather than just spending transactions.

What does CSFS help?

So, what exactly is this good for? What is the use of checking signatures against any message on the stack rather than against spending transactions?

First, in combination with CTV, it can provide the same functionality as what lightning developers wanted from the start. This was originally proposed as a new Sighash flag for signatures (a field that determines which part of the transaction the signature applies to). This was necessary because it covers the transaction ID of the transaction that created the output that used the transaction signature. This means that the signature is valid only for transaction spending just output.

This is a desirable behavior for lightning, as it can eliminate channel penalties. For each past lightning state, a penalty key and transaction are required to prevent the channel’s counterparty from trying to claim funds that are not owned. They try and you can charge all their money. A great feature is that in order to “attach” current state transactions to previous ones, by properly distributing the funds rather than confiscating them, allowing them to stop attempts at theft.

This can be achieved using basic scripts that employ CTV hashing and signatures that are checked using CSFS. This allows the transaction hash signed by that CSFS key to use the output created by this script.

Another useful feature is delegating control of UTXO. Other variables, such as new public keys, can be passed to the script in the same way that a CTV hash signed by a CSFS key can be used effectively for UTXO using the script designed for this purpose. You can build a script that allows CSFS keys to sign off Any A public key that is verified using CSFS and can be used for normal checking verification. This allows you to delegate the ability to use UTXO to others without moving in a chain.

Finally, in conjunction with CAT, CSF can be used to construct a much more complex introspection function. However, as seen later in the series, only CAT can do so, so CSFS doesn’t really need to emulate any of this more advanced behavior.

Close thoughts

CSFS is a very basic opcode, offering simple useful features with its own rights, and even the simplest contract opcodes are very well organized to create very useful features. The above example on floating signatures specifically refers to Lightning networks, but floating signatures are generally useful primitives that apply to protocols built into Bitcoin using pre-signed transactions.

In addition to floating signatures, script delegation is a very useful primitive and generalizes well beyond delegating control over UTXO to a new public key. The same basic functionality as “sideloading” variables after facts to script validation flow can be applied to anything, not just public keys. Time lock values, hash lock pre-image, etc. Scripts that hardcode the variables to be validated are now dynamically added after facts.

On top of that, CSFS is a very mature proposal. Since 2016, there are implementations that exist in liquid networks and elements (using liquids in the code base). Plus, Bitcoin Cash has its version since 2018.

CSFS is a very mature proposal and as long as I’ve been in this field, it goes back conceptually as long as I have multiple mature implementations and very clear use cases where I can apply them.

This is the first in a series that delves deep into individual contract proposals that have reached maturity worthy of depth failure.

Jeremy Rubin’s proposal for CheckTemplateVerify (CTV) with BIP 119 is the most mature and fully fleshed out contract proposal, not just from the proposals we cover, but from the whole of all contract proposals. As mentioned in the introductory article in this series, the ecosystem has many concerns about contracts that are too flexible that allow for extremely detrimental results for Bitcoin.

CTV was specifically designed to constrain its functionality sufficiently to avoid those concerns. First, to understand how CTV works, you need to understand the individual parts of a Bitcoin transaction.

This is a very high level view of Bitcoin transactions. There are new unheaded coins that the transaction creates when it is verified in blocks. There are many works that we pass through, and this is the highest level view of the structure of a transaction.

All transactions also have a transaction-wide version number field, indicating the applicability of a new version of a rule or feature. It also has markers and flags, set to a specific value indicating that the transaction uses SEGWIT. After this, the number of inputs and the number of transaction inputs. Next, the actual input comes.

Each input contains the TXID of the transaction that created the unused coin, what the output of that transaction is being used, the size of the Scriptsig, and a Vout that marks the sequence number where the unlock script script rules grant the script that will be approved by the lock script rules and the sequence number that will be used successfully. That is, the input has been around for a certain number of blocks or lengths since its creation.

Output count is the number of outputs for the following data, transactions: After this, we’ll see the actual output, including the amount of atshis allocated to that output, the ScriptPubkey size, and the actual ScriptPubkey, which is the lock script for that output. Finally, the Nlocktime field applies the time-lock value of the timestamp or block height that is applied to the entire transaction.

Each Segwit transaction also includes a witness section that contains the corresponding witness, which contains the count of stack items in each input, what is in the script stack, the size field for each item, and the actual data items to move into the stack.

How CTV works

CTV is an opcode that allows for the most basic form of introspection and transfer data carried out from all contract proposals. This allows the script to get a predefined 32-byte hash and compare it with the hash of most fields in the expenditure transaction. If the hash derived from the actual expenditure transaction does not match the predefined hash, the transaction is invalid.

The fields it commits are:

• nversion
• nlocktime
• Number of inputs
• Hashing of all n-sequence fields
• Output count
• Hashing of all outputs
• Input index (where the input is in a transaction, first input, second etc.)

These are all fields committed by the CTV hash, and the whole is not entirely capable of selecting and selecting. This is the degree to which introspection CTV is enabled. “Does the hash of these fields in the expenditure transaction match the hash of the lock script of the input being used?” A hash essentially commits the entire transaction, except for the actual input. There is a reason the hash does not contain input. To lock the output to a 32-byte hash using CTV, you need to know the hash of the transaction, the only way it is used. Inputs locked using CTV must include this hash to validate against CTV. That requires a hash of that transaction in front Create a complete transaction. That’s not possible.

You can also nest CTV scripts. This means that you can also commit the first CTV script to a transaction using output that also includes the CTV script. This allows CTV to “move” the data. In reality, anything data is contained in the transaction chain. This can theoretically be done to infinite depths, but in practice it is limited to a finite depth, as nesting must be generated in the last direction. This is because each level, or “hop”, requires that the hash of the transaction be moved to the next level. Otherwise, you will not be able to create a lock script first. If you don’t know the next transaction yet, you cannot generate the previous transaction.

What is CTV?

With CTV, you limit the output so that it can only be used by accurate, predefined transactions according to consensus rules. Some of you may be asking what a big deal is, but we can already pre-sign the transaction. If the level of introspection is so limited that you can only achieve what you can do by signing, what is the value?

First, pre-signed transactions always keep open the possibility of signing new transactions and spending those coins differently. You need to trust that the keychain doesn’t do this or trust that it removes the keys needed to sign (this should also be trusted). CTV removes that trust entirely. Once an expenditure transaction is defined and output is created in its CTV hash, there is no chance that it will be spent in another way implemented by consensus.

Currently, the only way to avoid that trust is to engage in a signature transaction yourself using Multisig. Secondly, unless you choose to sign it yourself, you can be completely certain that you cannot create other valid transactions that use the coin in a different way. The problem is that the more people are involved, the more difficult and unreliable, the more coordinated everyone and pre-signing transactions at the same time. The small sizes of the past become completely impractical to ensure that they are resolved.

CTV provides a way for people to know that a series of transactions are committed without everyone coming online for them to sign. By making the necessary information available to everyone as much as possible, it greatly simplifies the adjustment process. Also, having that person’s information allows you to create a chain of CTV transactions without the involvement of others.

It’s very valuable, but CTV can also be combined with other opcodes to allow for something even more valuable.

Close thoughts

CTV is a strictly limited contract that allows for some degree of introspection and forward-looking data transport, and is limited to the extent that it does not exceed the actual functionality that can be performed in pre-signed transactions. Rather than enabling new features on its own, value propositions significantly improve the efficiency, scalability, and security assurance of what can now be built using pre-signed transactions. This alone is a great advantage for almost any protocol currently being deployed, using pre-signed transactions.

Here we present some of the projects we have thoroughly implemented the comparison of this particular agreement with other agreements and investigated.

• Example of a basic payment pool with Stutxo.
• Implementation of CTV Vault by James O’Beirne proposed OP_VAULT (still using CTV).
• The proof-of-concept port for a pre-signed transaction-based ARK implementation from the second by Steven Roose uses CTV instead.
• Jeremy Rubin’s own Sapio language is a higher level language for building contracts with CTV (also supports the use of pre-signed transactions instead).
• A very basic coin pool design proposal by Timeout Tree, John Law.
• There are many other protocols, such as optimized, discreet logging agreements (DLCs), non-interactive lightning channels that one party can open without the other, and even decentralized ways for miners to pool together.

CTV is a very mature proposal at this point, with high value and no risk of enabling anything that encourages contract concerns. This should not only be considered very seriously, but in my personal opinion it should have been revitalized many years ago.