Covenant : a typically formal, serious, and binding arrangement.
This term has emerged as one of the most loaded terms in the Bitcoin arena. They are the greatest innovation since sliced bread. They are also the most perilous development since the atomic bomb. They aren’t genuinely going to enhance Bitcoin’s scalability, but they are intriguing.
Everyone possesses a distinctly different perspective towards them. We have the proponents, the opponents, and the neutral crowd. To complicate matters, the term covenant is honestly quite ambiguous in its delineation of mature and concrete proposals to the protocol that would fall under the category of covenants.
The variations in functionality among the various proposals that have been suggested are vast. Some proposals create entirely innovative design landscapes for what can be constructed atop Bitcoin, while others, strictly speaking, don’t provide any new functionality, simply optimizing existing processes that are currently feasible with significant complexity and overhead.
Let’s formulate a new definition specific to Bitcoin.
Covenant : any script that ensures some, or all, of the outputs produced by a transaction utilizing an input with a covenant script must meet specific criteria for the spending transaction to be considered consensus valid.
In less rigid terms, if a Bitcoin script currently limits who can utilize a coin by necessitating proof of authorization, for instance, a cryptographic signature, or when it can be accessed, such as after a timelock concludes or the spender can exhibit the preimage to a hash, a covenant script limits how it can be used, for example, to whom, the amount to which person, etc. A covenant script can even stipulate that a coin must be spent to another covenant script.
That last aspect is the heart of what has made covenant such a divisive term. Many individuals harbor significant reservations about introducing a new means to “lock” bitcoins that could self-replicate and ensure future coins are confined in a similar manner. There are substantial concerns regarding this being utilized to undermine fungibility or establish censorship mechanisms.
I find it crucial to highlight that both of these issues can be addressed at present, without covenant script capabilities, merely by employing multisig. Any authoritative entity can deny the processing of withdrawals from exchanges unless they are directed to a 2-of-2 multisig where that authority retains one key. Subsequently, they can simply decline to sign transactions directed to addresses where they do not possess a necessary key, and establish any blacklist or whitelist schema they prefer in an opaque and entirely off-chain manner.
That being said, it remains essential for Bitcoin users to understand the distinction of power and adaptability among the diverse covenant proposals that currently exist.
There are two fundamental aspects that covenants aim to facilitate in order to impose restrictions on how coins are allocated, introspection and forward data carrying.
Introspection refers to the capability of examining different components of the transaction that is being analyzed while attempting to spend a specific coin. For instance, if you wish to limit a coin so that it has to be spent to a defined address, you must be able to compare the address specified in the input’s covenant script with the address indicated in the output of the transaction spending it. Opcodes that enable introspection grant us the ability to compare various sections of the spending transaction against the limitations incorporated in the script under evaluation. The more detailed you can be with introspection regarding which specific elements of a transaction you can scrutinize, the more powerful it becomes.
Forward data carrying is related to introspection, and in many respects, it is a consequence of it, allowing you to ensure some piece of information is carried forward and included in each new covenant script so that it can be utilized in the subsequent evaluation of the covenant script. This is accomplished by utilizing introspection to restrict certain aspects of the transaction so stringently that they must include the exact required data or they are invalid. The more potent your introspective capability, the more flexibly you can carry data forward, and the more versatile you can be with that data.
This constitutes the initial introduction to a series of articles to come over the next few weeks examining all the major covenant proposals that are in a developed state, have garnered recent interest, or are conceptually significant enough that developers concur on their applicability but not yet a concrete design. This will not be entirely exhaustive, but it will be fairly comprehensive. A few of them also do not strictly qualify as covenants, yet integrate very intimately with them.
These will encompass:
- CHECKTEMPLATEVERIFY
- CHECKSIGFROMSTACK
- TXHASH
- OP_VAULT
- CHECKCONTRACTVERIFY
- CAT
- TWEAKVERIFY
