Bitcoin programmable solution Introvection and Covenant detailed explanation

Author: Chakra; Compilation: 0xjs@作作作作作

This article is the Part III published by Bitcoin Expansion series published by Chakra.

The first part refers to the previous article “>Bitcoin native expansion scheme review: Segwit and taproot“,,

The second part refers to the previous article “>Bitcoin scalability: Layer2 solution and related project analysis“” “.

The third part is this article, as follows:

Overview

Compared with the comprehensive blockchain such as Ethereum, Bitcoin script is considered to be extremely limited, and can only perform basic operations, and does not even support multiplication and removal.More importantly, the data of the blockchain itself can hardly be accessed by scripts, resulting in serious deficiencies in flexibility and programming.Therefore, people have been working hard to let the bitcoin script realize the introspecture.

Internal province refers to the ability of Bitcoin script inspection and restraint transaction data.This allows the script to control the use of funds based on specific transaction details to achieve more complex functions.At present, most Bitcoin operating codes either push the data provided by the user to the stack or manipulate existing data on the stack.However, the internal operation code can push the current transaction data (such as timestamp, amount, TXID, etc.) to the stack, so that UTXO expenditures can be more finely controlled.

As of now, there are only three main operating codes in Bitcoin scripts to support the province: CheckLocktimeVerify, ChecksequEnceverify and Checksig, and its variants CheckSigverify, Checksigadd, Checkmultisig, and Checkmulti. SIGVERIFY.

Contract (Covenant can also be translated as “restrictions”). Simply put, it refers to the restrictions on the monetary transfer method, allowing users to specify the distribution method of UTXO.Many contracts are achieved through the internal provincial operating code. Discussions on the province have now been classified under the theme of the Bitcoin OPTECH contract.

Bitcoin currently has two contracts, CSV (ChecksequEnceverify) and CLTV (CheckLocktimeverIFY). These two contracts are based on time -based contracts and are the basis for many expansion solutions (such as Lightning Network).This shows that the expansion solution of Bitcoin is seriously dependent on the province and contract.

How do we add conditions to the transfer of tokens?In the field of cryptocurrencies, our most commonly used method is to achieve through commitment and usually through hash.In order to prove that the transfer requirements are met, the signature mechanism is also required to verify.Therefore, there are many adjustments to hash and signatures in the contract.

Below, we will describe the Covenant operating code proposal widely discussed.

CTV (CheckTemplateify) BIP-119

CTV (CheckTemplatingverify) is a Bitcoin upgrade proposal in BIP-119, which has attracted widespread attention from the community.CTV allows output scripts to specify templates in transactions, including Nversion, NLOCKTIME, Scriptsig hash, input counting, sequence hash, output counting, output hash, input index and other fields.These template limits are implemented by hash promises. When the funds are spent, the script will check whether the hash value of the specified field in the expenditure transaction is matched with the hash value in the input script.This effectively limits the time, methods and quantities of the UTXO future transaction.

It is worth noting that the input TXID is excluded from this hash.This exclusion is necessary because in traditional and isolation witnesses, when using the default SIGHASH_ALL signature type, TXID depends on the value in Scriptpubkey.Including TXID can cause circulation dependencies in hash commitments and cannot be constructed.

CTV’s internal method is to directly pull the specified transaction information for hash operations, and then compare with the commitment on the stack.This internal province requires low requirements for chain space, but lacks certain flexibility.

The basis of the Bitcoin 2 -layer solution (such as Lightning Network) is the nominated transaction.Pre -signing usually refers to generating and signing transactions in advance, but not broadcast them before meeting certain conditions.In essence, CTV implements a more stringent pre -sign -nickname form, publishing the pre -signed promises on the chain and limited to the predefined template.

CTV was originally proposed to alleviate the congestion of Bitcoin, which can also be called congested control.When the congestion is serious, CTV can promise multiple future transactions in a single transaction to avoid broadcasting multiple transactions during peak hours, and complete actual transactions after the congestion is relieved.This may be particularly useful during the exchanges.In addition, the template can be used to implement VAULT to prevent hacking.Since the flow of funds is pre -determined, hackers cannot use the CTV script to point UTXO to their address.

CTV can significantly enhance the second layer of network.For example, in the lightning network, CTV can create a timeout tree and channel factories by extending a single UTXO to a CTV tree. It only needs to be traded and confirmed to open multiple state channels.In addition, CTV also supports atomic transactions in the ARK protocol through ATLC.

APO (SIGHASH_ANYPREVOUT) BIP-118

BIP-118 introduced a new type of signature hash logo to TapScript, which aims to promote more flexible expenditure logic, called Sighash_anyprevout.APO and CTV have many similarities.When solving the cycle between SCRIPTPUBKEYS and TXID, the APO method is to eliminate the relevant input information and sign the output only, so that the transaction is allowed to dynamically bind to different UTXO.

Logically, the signature verification operation OP_CHECKSIG (and its variants) execute three functions:

1. Each part of the assembly expenditure transaction.

2. Hachs for them.

3. Verify whether the hash has been signed by a given key.

The specific details of the signature are very flexible, and the SIGHASH logo determines which fields of the transaction.According to the definition of the signature operation code in BIP 342, the Sighash logo is divided into Sighash_all, Sighash_none, Sighash_SINGLE and SighashoneCanPay.SIGHASH_ANYONECANPAY controls input, while other control output.

SIGHASH_ALL is the default Sighash logo to sign all outputs; Sighash_none does not sign any output; SIGHASH_SINGLE signature specific output.SIGHASH_ANYONECANPAY can be set with the first three Sighash logos.If SIGHASH_ANYONECANPAY is set, only the specified input is signed; otherwise, all inputs must be signed.

Obviously, these Sighash logos cannot eliminate the impact of input, even if it is SIGHASH_ANYONECANPAY, it also needs to promise a input.

Therefore, BIP 118 proposes Sighash_anyprevout.The APO signature does not need to be promised to input UTXO (referred to as Prevout), but only needs to sign the output to provide greater flexibility for Bitcoin control.By pre -constructing transactions and creating corresponding one -time signatures and public keys, the assets sent to the public key address must be used by pre -constructed transactions to achieve contracts.The flexibility of the APO can also be used for transaction repair; if the transaction is stuck on the chain due to the low cost, it can easily create another transaction to increase the cost without a new signature.In addition, for multiple signature wallets, not relying on inputs that have been spent will make the operation more convenient.

Due to eliminating the cycle between Scriptpubkeys and input TXID, the APO can execute the internal province by adding output data to the Witness, although this still requires additional Witness space consumption.

For lintests such as Lightning Networks and VAULTS (VAULTS), the APO reduces the needs of preserving the intermediate state, and greatly reduces the storage requirements and complexity.The most direct use case of the APO is ELTOO. It simplifies the channel factory, builds a lightweight and cheap observation tower, and allows unilateral exit without leaving an error state, which enhances the performance of the lightning network in many aspects.The APO can also be used to simulate the CTV function, although it requires individuals to store signature and pre -signature transactions, which is more expensive and more efficient than CTV.

The main criticism of APO is concentrated in it requires a new key version, and this cannot be achieved by simple backward compatibility.In addition, the new signature hash type may bring potential risks of dual payment.After a wide range of community discussions, APO has added conventional signatures to the original signature mechanism to alleviate security concerns, thus obtaining the BIP-118 code.

OP_VAULT BIP-345

BIP-345 proposes to add two new operating codes, OP_VAULT and OP_VAULT_RECOVER. When they are used with CTV, they can achieve special contracts, allowing users to force users to delay the use of specific currencies.During this delay, transactions performed before the recovery path “revoke”.

Users can create Vault by creating a specific Taproot address. This address must include at least two scripts in its MAST: one with OP_VAULT operating codes to promote the expected withdrawal process, and the other with OP_VAULT_RECOVER operating code to ensure that it is picking upYou can restore the tokens at any time before completion.

How does OP_VAULT implement interrupted time -locking withdrawal withdrawal?OP_VAULT is implemented by replacing the OP_VAULT script used by a specified script, so as to effectively update the single leaf of MAST, while maintaining the remaining TAPROOT leaf nodes unchanged.This design is similar to TLUV, but OP_VAULT does not support the update of internal keys.

By introducing templates during the script update, you can limit payment.The number of time locks is specified by OP_VAULT. The template of the CTV operating code restricts the output set that can be used through this script path.

BIP-345 is designed for Vaults. It uses OP_VAULT and OP_VAULT_RECOVER to provide users with a safe hosting method. It uses a highly secure key (such as paper wallet or distributed multiple signatures) as a recovery path, and at the same time configures a certain delay for regular payment.The user’s device will continue to monitor the expenditure of the insurance library. If an accidental transfer occurs, the user can start recovery.

The cost problem is needed to implement VAULT through BIP-345, especially for restoration of transactions.Possible solutions include CPFP (sub -node is paid by the parent node), temporary anchor point and new Sighash_group signature hash logo.

TLUV (TAPLEAFUPDATEVERIFY)

The TLUV scheme is built around Taproot, which aims to effectively solve the problem of sharing UTXO exit.The guidance principle is that when the Taproot output is used, the internal keys and MAST (TAPScript Trie) can be partially updated by encrypted conversion and the internal structure of the Taproot address, as mentioned in the Tluv script.This makes the implementation of the Covenant function possible.

The concept of the TLUV scheme is to create a new Taproot address by introducing the new operating code TAPLEAF_UPDATE_VERIFY.This can be implemented by performing the following or multiple operations:

Update the internal key
Pruning Merkle path
Delete the script currently being executed
Add new steps to the end of the Merkle path

Specifically, TLUV accepts three inputs:

Specify how to update the internal public key.
Specify a new step for the Merkle path.
Specify how many steps to delete the current script and/or to trim the Merkle path.

The TLUV operating code calculates the updated scriptpubkey and verifies whether the current input corresponding output is spent on this scriptpubkey.

Tluv’s inspiration comes from the concept of CoinPool.Nowadays, the United fund pool only needs to sign a pre -signature transaction to create, but if you want to exit without a license, you need to create a double signature signature.TLUV allows to exit without licensed permits, no pre -signature.For example, a group partner can use Taproot to build a shared UTXO to bring together their funds.They can use the TAPROOT key to transfer funds internally, or they can jointly sign to initiate payment outside.Individuals can withdraw from the shared fund pool at any time to delete their payment path, and others can still complete the payment through the original path, and the individual’s exit will not expose other information about other people inside.Compared with non -pooling transactions, this model is more efficient and more private.

The TLUV operating code has implemented some expenditure limit by updating the original Taproot Trie, but it does not realize a self -introspection of the output amount.Therefore, a new operating code in_out_amount is needed.This operating code pushes the two items to the stack: the UTXO amount and the corresponding output amount of this input, and then the people using TLUV need to use the mathematical computing symbol to verify whether the funds are appropriately retained in the updated scriptpubkey.

Internal provinces with output amounts increase complexity, because the amount of Satoshis is required to be represented by up to 51 digits, but the script only allows 32 -digit mathematical operations.This requires redefining the operating code behavior to upgrade the operator in the script or use the size_group to replace the in_out_amount.

TLUV has the potential to become a solution to the 2nd floor of the decentralization, but its reliability of adjusting Taproot Trie still needs to be confirmed.

Matt

Matt (Merkleize all the thing) aims to achieve three goals: Merkleizing The State, Merkleizing The Script, Merkleizing The Performing, to achieve general smart contracts.

Merkleizing the state: This involves building Merkle Trie, where each leaf node represents the hash value of a state, while Merkle ROOT reflects the overall state of the contract.
Merkleizing the script: This refers to the use of TapScript to form a MAST, where each leaf node represents a possible state conversion path.
Merkleizing the Performing: Merkleization is performed through the encrypted commitment and fraud challenge mechanism.For any calculation function, the participants can calculate under the chain, and then post commitment f (x) = y.If other participants find the error result f (x) = z, they can launch a challenge.The arbitration is performed through a two -point search, similar to the principle of Optimistic Rollup.

Merkel’s execution

In order to achieve MATT, the Bitcoin script language needs to have the following functions:

Mandatory output has a specific script (and the number of it)
Attach a piece of data to the output
Read data from the current input (or another input)

The second point is important: dynamic data means that the state can be calculated through the input data provided by consumers, because this allows analog state machine to determine the next state and additional data.The MATT scheme is implemented through OP_CHECONTRACTRACTVERIFY (OP_CCV) operation code. The operating code is the previously proposed OP_CHECKOUTPUTCONTRACTRACTVERFY and OP_CHECKINPUTCONTRACTVERIFY. Target.

Control output amount: The most direct method is to directly province; however, the output amount is 64 digits and requires 64 -bit arithmetic, which brings great complexity in the Bitcoin script.OP_CCV uses a delay check method, such as OP_VAULT, where the input amount of all inputs output in the CCV is added as the lower limit of the output amount.The delay is because this test occurs during the transaction, not during the script assessment input.

In view of the universality of fraud proof, some variants of MATT contracts should be able to achieve all types of smart contracts or 2 layers of structures, although additional requirements are required (such as capital locking and delay in challenge);The program can accept the transaction.For example, using an encrypted commitment and fraud challenge mechanism to simulate the OP_ZK_verify function, and realize ROLLUPs without trust on Bitcoin.

In practice, things have happened.Johan Toras HalSeth uses the OP_CHECKCONTRACTRACTRACTRACTRACTRACTVERIFY operating code in the MATT soft fork proposal to achieve ELFTRACE, which allows any program that supports RISC-V compilation to verify on the Bitcoin blockchain, so that one of the contracts in the contract agreement can pass the contract through the contract.Verification to access funds, so that the bridge is received by Bitcoin native verification.

CSFS (OP_CHECKSIGFROMSTACK)

From the introduction of the APO operating code, we learned that OP_CHECKSIG (and its related operations) is responsible for assembling transactions, hash computing and verification signatures.However, these operational verification messages are traded by serialized by the operation code and are not allowed to specify any other messages.Simply put, the role of OP_CHECKSIG (and its related operations) is to verify whether the UTXO spent as a transaction is authorized by the signature holder to use the signature mechanism to protect the security of Bitcoin.

CSFS, as the name suggests, is to check the signature from the stack.The CSFS operating code receives three parameters from the stack: signature, message and public key, and verify the effectiveness of the signature.This means that people can pass on any news to the stack and verify through CSFS to achieve some innovations of Bitcoin.

The flexibility of CSFS enables them to realize mechanisms such as payment signatures, authorization entrustment, prophecy contract contracts, dual payment protection guarantees, and more important transaction self -introspection.The principle of using CSFS for transaction is very simple: if the transaction content used by OP_CHECKSIG is pushed to the stack by witnesses, and uses the same public key and signatures to verify OP_CSFS and OP_CHECKSIG, and if both verification is successfully passed, transmitAny message content for OP_CSFS is the same as serialized expenditure transactions (as other data) of OP_CHECKSIG hidden use.We then obtain verified transaction data on the stack, which can be used to restrict the expenditure transaction using other operating codes.

CSFS often appears with OP_CAT, because OP_CAT can connect to different fields of transactions to complete serialization, so as to more accurately select the transaction fields required by the province.Without OP_CAT, the script cannot be re -calculated from the data that can be checked separately. Therefore, what it can really do is to check whether the hash value corresponds to a specific value, which meansEssence

CSFS can implement operating codes such as CLTV, CSV, CTV, APO, making it a multi -functional saving operating code.Therefore, it also helps the scalability solution of Bitcoin 2.The disadvantage is that it needs to add a complete copy of the signature transaction to the stack, which may significantly increase the size of the transaction using CSFS.In contrast, the saving overhead of the saving operating code in a single purpose like CLTV and CSV is very small, but it is necessary to make consensus changes to add each new special inner provincial operating code.

Txhash (OP_TXHASH)

OP_TXHASH is a simple internal provincial operating code that allows Operator to choose specific fields and push it to the stack.Specifically, OP_TXHASH pops up a TXHASH logo from the stack, calculates (label with tags) txhash, and then push the generated hash back to the stack.

Due to the similarity of TXHASH and CTV, a large number of discussions in the community have a large number of discussions in the two.

TXHASH can be regarded as a general upgrade of CTV. It provides more advanced trading templates, allowing users to clearly specify the various parts of the expenditure transaction and solve many problems related to transaction costs.Unlike other Covenant operating codes, TXHASH does not need to witness the necessary data in the test, which further reduces the storage requirements. Unlike CTV, TXHASH is not compatible with NOP and can only be implemented in TAPScript; combinations of TXHASH and CSFS can be used as CTV and APOs.Replacement scheme.

From the perspective of constructing a contract, TXHASH is more conducive to creating a “additional contract”. Among them, all the transaction data parts you want to repair are pushed to the stack, handled with hash, and verify whether the hash generated has a fixed value and the fixed valueMatching; CTV is more suitable for creating a “subtraction contract”. Among them, all the transaction data parts you want to keep free are pushed to the stack.Then, use the rolling SHA256 operating code. The hash processing starts from a fixed intermediate state, and the state is submitted to the prefix of the trading hash data.The freedom is beh to this middle state.

The TXFieldSelector field defined in the TXHASH specification is expected to expand to other operating codes, such as OP_TX.

BIP related to TXHASH is currently in DRAFT on Github and has not yet been distributed.

OP_CAT

OP_CAT is a mysterious operating code. It was originally abandoned by Satoshi Nakamoto because of security considerations, but recently triggered a fierce discussion among the core developers of Bitcoin, and even set off Meme culture on the Internet.In the end, OP_CAT was approved under BIP-347, which is called the most likely BIP proposal recently.

In fact, OP_CAT’s behavior is very simple: it connects two elements from the stack.How does it implement the Covenant function?

In fact, the ability to connect two elements corresponds to a powerful encrypted data structure: Merkle Trie.To build Merkle Trie, you only need to connect and hash operations, and the Bitcoin script provides hash functions.Therefore, using OP_CAT, we can theoretically verify Merkle to prove that this is one of the most common lightweight verification methods in blockchain technology.

As mentioned earlier, CSFS can achieve a common Covenant solution with the help of OP_CAT.In fact, even if there is no CSFS, OP_CAT itself can realize the province of transactions by using the structure signed by Schnorr.

In Schnorr’s signature, the message that needs to be signed is composed of the following fields:

These fields include the main elements of the transaction.By putting them in Scriptpubkey or Witness, and using OP_CAT binding OP_SHA256, we can construct a Schnorr signature and use OP_CHECKSIG for verification.If the verification is passed, the stack will retain the verified transaction data to achieve the transaction from the introspection.This enables us to extract and “check” each part, such as its input, output, target address or bitcoin involved.

Regarding specific password science, you can refer to the article “Cat and Schnorr Tricks” by Andrew Poelstra.

All in all, OP_CAT’s versatility enables it to simulate almost any Covenant operating code.Many Covenant operating codes depend on the function of OP_CAT, which greatly improves its position in the merger table.Theoretically, relying on OP_CAT and the existing bitcoin operating code, we hope to build a trusted BTC ZK Rollup.Starknet, Chakra and other ecosystem partners are actively promoting the realization of this goal.

in conclusion

When we explore the various strategies of expanding Bitcoin and enhancing its programmicality, it is obvious that the roads that move forward involve the fusion of native improvement, chain calculation and complex script functions.

If there is no flexible basic layer, it is impossible to build a more flexible two -layer.

The calculation expansion under the chain is a future trend, but the programming of Bitcoin needs breakthroughs in order to better support this scalability and become a real global currency.

However, the computing nature on Bitcoin is fundamentally different from the computing nature of Ethereum.Bitcoin only supports “verification” as a computing form and cannot perform general computing, and Ethereum is essentially computing. Verification is a calculated by -product.It can be seen from one point: Ethereum charges GAS Fee to the unreasonable transactions, while Bitcoin is not charged.

Contract is a smart contract based on verification rather than computing.In addition to a few Nakamoto Treasury, it seems that everyone thinks that contracts are a good choice to improve Bitcoin.However, the community is still fiercely arguing which method should be used to implement the contract.

APO, OP_VAULT, and TLUV are directly applied. Choosing these three methods can be cheaper and efficiently achieve specific applications.Lightning network enthusiasts will choose APOs to achieve LN-SYMMetry; users who want to achieve Vault are best to use OP_VAULT; and for buildingPool, TLUV can provide better privacy and efficiency.OP_CAT and TXHASH are more abundant, and the probability of security vulnerabilities is smaller. Combining with other operating codes can achieve more cases, but the cost may be that the script complexity increases.CTV and CSFS have adjusted the blockchain processing method, CTV implements delayed output, and CSFS realizes delayed signatures.MATT stands out with the strategy of optimistic execution and fraud proof, and uses the Merkle Trie structure to achieve general smart contracts, but the provincial function still requires new operating codes.

We see that the Bitcoin community is actively discussing the possibility of obtaining Covenants through soft forks.Starknet has officially announced the addition of Bitcoin ecosystem, and plans to achieve settlement on the Bitcoin network within six months after the merger of OP_CAT.Chakra will continue to pay attention to the latest developments of the Bitcoin ecosystem, promote the merger of OP_CAT soft forks, and use the programmatic construction of Covenants to build a safer and more efficient Bitcoin settlement layer.