It is part two of a series. series A detailed analysis of individual covenants that are mature enough to warrant a thorough breakdown.
CHECKSIGFROMSTACK Brandon Black and Jeremy Rubin’s (CSFS) proposal for BIP348 with Brandon Black is not a contract. As I mentioned in my introductory article, I’ll be covering some proposals that aren’t covenants. However, they do synergize and/or interrelate in a certain way with those covenants. CSFS, for example, is a good first step.
CSFS can be a relatively simple opcode. However, before we look into how it functions let’s first take a closer look at how a Bitcoin Script actually operates.
It is an Stack-based Language. This means data is stored in stacks. “stacked” The stack is stacked on top of one another, with the opcodes being applied by either returning data to the top or the result of an operation.
When a script is executed and checked, it has two distinct parts. “witness” The witness/unlocking script is included with the output. This witness/unlocking Script is “added” The stack is built from the right side to the left of the lock script. Take a look at the example below. “|” The witness must mark the boundaries between script and the witnesses.
1 2 | OP_ADD 3 OP_EQUAL
The example code adds value to the script “1” The value is added to the pile. “2” On top of this. OP_ADD adds the two top elements and puts the result on the stack. “3”). ” “3” This is added to the stack. The final item, OP_EQUAL takes the two highest items in the stack, and returns a “1” Numbers and True/False are both represented in the 1 and 0 stack.
If the transaction is invalid, the consensus will be considered to have failed.
Here is an example of the basic pay-to pubkey-hash script (P2PKH). The legacy addresses begin with the letter a “1”:
The public key and signature are first added to the stack. DUP, which duplicates and then returns the item on top to the stack, is next called. HASH160 returns the hash of the public key duplication to the top item in the stack. The script’s public key hash is placed on the top of the pile. It works the same way as EQUAL. The two items at the top of the stack are grabbed and the result is returned either 1 or 0, depending on whether the item was a 1. EQUALVERIFY runs VERIFY, which removes and fails the transaction if top item of stack isn’t 1. CHECKSIG, the final step, grabs both the pubkey and the signature from the stack, assuming they are a signature. It then checks the signature against the hash value of the transaction. It will place a 1 at the top of stack if it’s valid.
What is CSFS?
CHECKSIG has been one of the more popular opcodes for Bitcoin. Every single transaction uses this opcode in its script, almost without exception. Bitcoin’s protocol relies on signature verification. There is very little flexibility when it comes to what you check the signature with. CHECKSIG only verifies a signature in relation to the transaction that is being checked. You can choose to be flexible, for example. There is some flexibility, i.e.
CSFS aims at changing this, by allowing a message to be pushed onto the stack directly and subsequently verified. This is an improvement over the current system which only allows signatures to be checked against transactions. Operational structure of the opcode is very simple:
The message is placed on the top, followed by the public-key. CSFS will then take the three highest items in the stack and verify the signature with the message. A 1 will be placed if the signature has been validated.
That’s it. The CHECKSIG variant that allows the user to enter arbitrary messages in addition to just spending transactions.
What is CSFS useful for?
What exactly does this do? Why check a signature on a stack of random messages instead of the actual spending transaction?
First, combine with CTV It can be used to provide functionality that Lightning developers wanted from the beginning: floating signatures which can be attached to various transactions. It was initially proposed as a sighash field for signatures. (The field which dictates to what part of a transactions a signature is applied). It was necessary because the signature of a transaction covers the ID of the original transaction. A signature can only be used for transactions that spend the output. The exact wording is not known. output.
It is the desired behaviour for Lightning, as it allows us to eliminate channel penalties. Each past Lightning transaction and key must be matched to the previous state to make sure that your counterparty does not try to use any to attempt to claim money they do not own. They can’t claim their funds unless they attempt to do so. You can simply use something superior if it allows you to do so. “attach” The current transaction should be compared to the previous transactions in order to prevent theft by correctly distributing the funds instead of confiscating the money.
A basic script can accomplish this by taking a CTV signature and putting it over a CTV-hash. This is then checked with CSFS. It would be possible to have any output created by this script spend any transaction signature signed by the CSFS key.
Delegation of control over a UTXO is another useful feature. The script can check if a CTV hash, signed by a CSFS, is valid to spend a UTXO. Other variables such as a newly created public key, can be added into the script. The script can be built to allow a CSFS Key to sign off. The following are some examples of how to use Public key that can be used to validate a CHECKSIG using CSFS. You could then delegate to someone else the power to spend a UTXO without moving it onto chain.
CSFS, when combined with CAT can create much more sophisticated introspection functionality. However, we’ll see in the next part of this series that CSFS does not need to be used to mimic any more complex behavior. CAT can do it.
Closed Thoughts
CSFS, a basic opcode which offers simple functionality on its own but also composes well with the simplest covenant opcodes in order to provide very useful functionality. The example of floating signatures above is specific to the Lightning Network. However, floating signatures can be used in any protocol that uses pre-signed Bitcoin transactions.
Script delegation goes beyond delegates control to a UTXO. This same ability is also available to “sideload” Variables can be added to a script after it has been run. This is not limited to public keys. Timelock values, hashlock preimages, etc. Now, any script which hardcodes an input variable for verification can have the values added dynamically afterward.
It is also a mature proposal. The implementation has been running on Liquid Network (the codebase Liquid is built upon) and Elements. since 2016. Bitcoin Cash, on the other hand, has a version Since 2018, it has been a part of the.
CSFS, a proposal with a long history, is a well-developed concept. I’ve been working in this area for almost the same amount of time. There are multiple mature implementations as well as very specific use cases that it can apply to.
“This article is not financial advice.”
“Always do your own research before making any type of investment.”
“ItsDailyCrypto is not responsible for any activities you perform outside ItsDailyCrypto.”
Source: bitcoinmagazine.com
