Source: Bitcoin Magazine; Translated by: Deng Tong, Golden Finance

Contract: Usually a formal, solemn, binding agreement.

The word has become one of the most popular words in the Bitcoin field. They are the best things since sliced ​​bread. They are the most dangerous things since the atomic bomb. They don't actually have any impact on Bitcoin's expansion, but they're great.

Everyone has a completely different attitude towards them. We have supporters, oppositions and conflicting factions. Worse, frankly, “contract” is a very vague term that describes the mature and specific proposals of agreements that will be classified as contracts.

The degree of difference between the functions of different proposals proposed is enormous. Some of them create entirely new design space for the possibility of building on top of Bitcoin, while others strictly don’t add any new features at all, they just optimize what is already possible, but with a lot of complexity and overhead.

Let's create a new definition specific to Bitcoin.

Contract: Any script that guarantees that some or all outputs generated by the exchange that is spent on input using a contract script must comply with certain specific criteria to enable the expenditure transaction to be valid.

So, in a less strict sense, if the Bitcoin script currently limits who can use a coin by requiring proof of authorization (i.e., cryptographic signature), or when it can be used, i.e. after the time lock expires or the user can display the original image to the hash, then the contract script limits how to use it, i.e. who to give it, how much to give to which person, etc. A contract script can even limit one coin so it must be spent on another contract script.

The last part is at the heart of such a controversial word for contract. Many people have a lot of reservations about adding a new way of "locking" Bitcoin, which can spread itself and ensure future coins are restricted in similar ways. Many people are worried that this will be used to undermine interchangeability or establish censorship.

I feel it is necessary to point out that both of these things can be done now, no contract scripting functionality is required, just use multi-signature. Any institution can refuse to allow withdrawals from exchanges unless they use a 2-of-2 multi-signature, which holds a key. From there, they can simply refuse to sign a transaction sent to the address they do not have the required key and build any blacklist or whitelist scheme they want completely off-chain in an opaque way.

Nevertheless, Bitcoin users still need to grasp and understand the power and flexibility differences between all the different contract proposals currently in existence.

To limit how Bitcoin is used, the contract seeks to implement two core functions, namely introspection and forward data transmission.

Introspection refers to the ability to check different parts of the transaction being evaluated when trying to use a specific bitcoin. So for example, if you want to limit the bitThe coin must be spent at a specific address, and it must be able to compare the address specified in the entered contract script with the address specified in the transaction output that spent the coin. Enabling the introspective opcode allows us to compare different parts of the spending transaction with the restrictions contained in the script being evaluated. Introspection is the more detailed it is to check which specific parts of a transaction can be examined, the stronger it is.

Forward data delivery is related to introspection and in many ways is the result of introspection, which allows you to ensure that certain information is passed and included in each new contract script for use the next time the contract script is evaluated. This is done by using introspection to strictly limit certain parts of the transaction so that they must contain the exact data they need or they will be invalid. The more introspective you have, the more flexibility you have in passing data and the more flexibility you have in using it.

This is just the first in a series of articles to be published in the coming weeks, which will cover all contract proposals that are in maturity, have recently received attention or are so conceptually that developers agree to its usefulness but have not yet been specifically designed. This won't be 100% done, but it will be relatively comprehensive. Some of them are not strictly contracts, but are closely related to them.

These will include:

Check template verification

Check signals from the stack

TXHASH

OP_VAULT

Check contract verification

Cat

Adjust verification