Covenant : a usually formal, solemn, and binding agreement.
This word has become one of the most charged words in the Bitcoin space. They’re the best thing since sliced bread. They’re the most dangerous thing since the atom bomb. They aren’t really going to do anything to scale Bitcoin, but they’re neat.
Everyone has a completely different attitude towards them. We have the pro-faction, the anti-faction, the ambivalent faction. To make matters worse, covenant is frankly a very vague term in its description of mature and concrete proposals to the protocol that would be classified as covenants.
The degrees of difference between the functionality of different proposals that have been put forward is enormous. Some of them create entirely new design spaces for what it is possible to build on top of Bitcoin, while others strictly speaking don’t add any new functionality at all, they simply optimize things that are already currently possible with a large degree of complexity and overhead.
Let’s create a new definition specific to Bitcoin.
Covenant : any script that guarantees some, or all, of the outputs created by a transaction spending an input with a covenant script will have to fit certain specified criteria for the spending transaction to be consensus valid.
So in less strict terms, if a Bitcoin script currently restricts who can spend a coin by demanding an authorization proof, i.e. a cryptographic signature, or when it can be spent, i.e. after a timelock expires or the spender can show the preimage to a hash, a covenant script restricts how it can be spent, i.e. to who, how much to which person, etc. A covenant script can even restrict a coin so that it must be spent to another covenant script.
That last part is the core of what has made covenant such a contentious word. Many people have large reservations about adding a new way to “lock” bitcoins that can self-propagate and ensure future coins are restricted in a similar fashion. Many people have concerns about this being used to damage fungibility or institute censorship regimes.
I feel it necessary to point out that both of these things can be accomplished right now, with no covenant script capability, simply by using multisig. Any authority can refuse to allow withdrawals to be processed from exchanges unless they are to a 2-of-2 multisig where that authority holds one key. From there they can simply refuse to sign transactions sending to addresses where they do not hold a required key, and establish whatever blacklist or whitelist scheme they desired opaquely and entirely off-chain.
That said, it is still important for Bitcoin users to have a grasp and understanding of the difference of power and flexibility between all the different covenant proposals that currently exist.
There are two core things that covenants seek to enable in order to apply restrictions to how coins are spent, introspection and forward data carrying.
Introspection is the ability to inspect different parts of the transaction that is being evaluated while trying to spend a specific coin. So for instance, if you want to restrict a coin so that it has to be spent to a specific address, you have to be able to compare the address specified in the input’s covenant script to the address specified in the output of the transaction spending it. Opcodes that enable introspection are ones that give us the ability to compare different parts of the spending transaction against restrictions included in the script being evaluated. The more granular you can get with introspection concerning which particular parts of a transaction you can examine, the more powerful it becomes.
Forward data carrying is related to introspection, and in many ways a consequence of it, that allows you to ensure some piece of information is carried forward and included in each new covenant script so that it can be used in the next evaluation of the covenant script. This is accomplished by using introspection to restrict certain parts of the transaction so tightly that they must include the exact desired data or they are invalid. The more powerful introspective capability you have, the more flexibly you can carry data forward, and the more flexibly you can use that data.
This is just the first introduction to a series of articles to 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 that developers agree on their usefulness but not yet a concrete design. This won’t be 100% complete, but it will be relatively comprehensive. A few of them also are not strictly covenants per se, but compose very tightly with them.
These will include:
- CHECKTEMPLATEVERIFY
- CHECKSIGFROMSTACK
- TXHASH
- OP_VAULT
- CHECKCONTRACTVERIFY
- CAT
- TWEAKVERIFY
