Covenant: A normal formal, solemn and binding deal.
This word has become one of the most charged words in the Bitcoin space. They are the best thing since the sliced ​​bread. They are the most dangerous thing since the nuclear bomb. They don’t really want to do anything to scale Bitcoin, but they are neat.
Everyone has a completely different attitude towards them. We have the pro-fraction, the anti-fraction, the ambivalent fraction. To make things worse, Covenant honestly is a very vague expression in his description of mature and concrete proposals for the protocol that would be classified as covenants.
The degree of difference between the functionality of various proposals that have been made are huge. Some of them create brand new design rooms for what it is possible to build on the top of Bitcoin, while others strictly add no new functionality at all, they simply optimize things that are already possible with a great deal of complexity and overhead.
Let’s create a new definition that is specific to Bitcoin.
Covenant: Any script that guarantees some or all of the output created by a transaction using an input with a pact script must fit certain specified criteria for the consumption of consumption being the validity of the agreement.
So in less strict terms if a Bitcoin script currently restricts Who can use a coin by requiring an authorization certificate, ie. a cryptographic signature or when It can be used, ie. After a time lock expires, or the spender can show the preimagen to a hash, a covenant script restricts how It can be used, ie. To whom, how much to what person, etc. A Covenant script can even limit a coin so it should be used for another covenant script.
The last part is at the heart of what has made the pact a so contentious word. Many people have great reservations about adding a new way of “locking” bitcoins that can self -propact and ensure future coins are limited in a similar way. Many people are concerned that this is used to harm fungalness or the institute censor regimes.
I feel it is necessary to point out that both of these things can be achieved right now, without Covenant -script capacity, simply by using Multisig. Any authority may refuse to allow withdrawals to be treated from exchanges unless they are for a 2-of-2 multi-mole where this authority has a key. From there, they can simply refuse to sign transactions that send to addresses where they do not have a required key, and establish the blacklist or whitelist scheme they wanted opaque and completely off-chain.
That said, it is still important for Bitcoin users to have a grip and understanding of the difference in power and flexibility between all the different covenant proposals that are currently available.
There are two core things that covenants seek to enable to apply restrictions to how Coins are used, Introspection and forward data.
Introspection is the ability to inspect different parts of the transaction that are evaluated while trying to use a particular coin. So, for example, if you want to limit a coin so that it is to be used for a specific address, you must be able to compare the address specified in the input’s pact script to the address specified in output from the transaction costs. Opcodes that enable introspection are the ones that give us the opportunity to compare different parts of the expense transaction with restrictions included in the script evaluated. The more granular you can get with introspection regarding which certain parts of a transaction you can investigate, the more powerful it becomes.
Forward data that carries is related to introspection, and in many ways a consequence of what allows you to ensure that a piece of information is performed and included in each new covenant script so that it can be used in the next evaluation of the covenant script. This is achieved by using introspection to limit certain parts of the transaction so closely that they must include the exact desired data or that they are invalid. The more powerful introspective capacity you have, the more flexible you can bring data forward and the more flexible you can use this data.
This is just the first introduction to a number of articles that come over the next few weeks looking at all the major covenant proposals that are in a mature state, have received recent interest or are conceptually critically important enough for developers to agree on their utility, but not yet a concrete design. This will not be 100% complete, but it will be relatively extensive. A few of them are also not strictly covenants in themselves, but compose very close with them.
These will include:
- CheckTemplateverify
- Checksigfromstack
- Txhash
- OP_VAULT
- CheckContractverify
- CAT
- Tweakverify