Contract: Usually formal, strict, binding agreement.
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, and 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: A script that guarantees some or all of the output created by a transaction must conform certain specified criteria for the expenditure transaction to be effective by spending input in a Covenant script.
In less strict terms, if the Bitcoin script currently limits who can use the coin by requesting a proof of authorization, that is, signing an encryption, that is, after the timelock has expired, that is, if the Spender can show a pre-image to a hash, then the contract script limits how it can be used. 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 using Multisig just requires me to point out that there is no contract scripting functionality and 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 are two cores that a contract is trying to take effect to apply restrictions on how coins are used, introspection, and transporting forward data.
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 CheckSigGromStack txhash op_vault checkcontractverify cat tweakverify
