contract: Usually formal, strict, binding contracts.
This word has become one of the most recharged words in the Bitcoin space. They are the best since sliced bread. They are the most dangerous since the atomic bomb. They're not going to do anything to actually scale Bitcoin, but they're neat.
Everyone has a completely different attitude towards them. We have profaction, anti-faction, ambiguous factions. Worse, contracts are frankly a very vague term in describing mature concrete proposals for protocols classified as contracts.
The differences in functionality of the various proposed proposals are very large. Some of them create a whole new design space for what can be built on top of Bitcoin, but technically there are others that don't add any new features at all.
Let's create a new definition specific to Bitcoin.
contract: Scripts that guarantee some or all of the output created by transactions that spend input using covenant scripts must meet certain specified criteria for the spending transaction to be consensus-enabled.
So if it's not that strict, if the bitcoin script is currently restricted Who is Using a coin by requesting a proof of approval, i.e., signing an encryption, or when It can be spent. That is, after the time lock has expired, or the spender can show pre-image to the hash, the contract script is restricted how It can be used, i.e., for whom, for how many people, for how many people, etc. The contract script must limit the coins and spend it on another contract script.
That last part is at the heart of what makes the contract a controversial word. Many people have a great reservation about adding new ways to self-propagate and “lock” Bitcoin that future coins are restricted in a similar way. Many people are concerned about this being forced to do or being used to establish a censorship system.
I feel that I need to point out that, simply using Multisig, without the contract scripting feature, both of these can be achieved right now. The authorities can refuse to allow withdrawals from the exchange to be processed from the exchange unless the authorities are two multisigs holding one key. From there, they simply refuse to send to addresses that do not hold the necessary keys, and can establish a blacklist or whitelist scheme that they wanted opaque and completely off-chain.
That being said, it remains important for Bitcoin users to understand and understand the differences in power and flexibility between all the different contract proposals currently in existence.
There can be two cores that a contract attempts to enable to apply restrictions how Coins will be used, Introduction and Forward data carrying.
Introduction is the ability to inspect various parts of a transaction that is being evaluated while attempting to use a particular coin. So, for example, if you want to limit the coins to be spent on a particular address, then the address specified in the input covenant script must be able to be compared to the address specified in the transaction expenditure output. An opcode that allows for introspection gives you the ability to compare it with the limitations contained in the script being evaluated. The more introspective you can get in terms of a particular part of a transaction that you can look up, the more powerful it becomes.
Carrying forward data is related to introspection, and as a result, in many respects, some information can be carried over and included in each new contract script and used in the next evaluation of the contract script. This is achieved by using introspection to very strictly limit certain parts of a transaction, which means that it includes accurate data for purpose or is invalid. The more powerful introspective you have, the more flexible you can move your data forward and use it more flexible.
This is just the first introduction to a series of articles coming over the coming weeks, examining all the major contract proposals that are in mature state, have received recent interest, or are so important that developers agree that their usefulness is yet to be a specific design. This won't be 100% complete, but it will be relatively comprehensive. Some of them are also not strictly the contract itself, but are structured very closely with them.
These include:
- CheckTemplateVerify
- ChecksigfromStack
- txhash
- op_vault
- CheckContractVerify
- cat
- TweakVerify
