In the world of Bitcoin, “covenant” has become quite a buzzword. For some, it’s the best innovation since sliced bread. Others see it as potentially dangerous, akin to the atom bomb. Still, there are voices that argue covenants may not do much to scale Bitcoin, but they’re certainly intriguing.
Opinions about covenants vary widely, creating camps of supporters, detractors, and those who remain indifferent. One complication is that the term itself is quite broad, covering a range of proposed updates to the Bitcoin protocol that might be classified as covenants.
These proposals differ significantly in functionality. Some open up entirely new possibilities for building on Bitcoin, while others mainly streamline existing processes without adding new capabilities. Yet, all this comes with a notable level of complexity.
Let’s hone in on a Bitcoin-specific definition:
A “covenant” is any script ensuring that certain outputs from a transaction conform to specified criteria to be considered valid under the consensus rules.
In simpler terms, if a Bitcoin script currently restricts spending by requiring authorization—like a cryptographic signature—or dictates when it can be spent, a covenant script focuses on how it can be spent. It might specify who receives the funds or require sending a specific amount. Crucially, a covenant can even stipulate that a coin only be spent through another covenant script.
This core functionality has stirred debate, mainly because it introduces a method to “lock” bitcoins in a way that could perpetuate restrictions, potentially affecting fungibility and enabling censorship.
It’s worth noting that similar outcomes can be achieved today without covenants, using multisig arrangements. An authority can mandate that withdrawals are processed through a multisig setup and refuse to sign transactions that don’t meet their criteria, thereby controlling what happens off-chain in a less transparent manner.
That said, it’s vital for Bitcoin users to understand the varying power and flexibility of the different covenant proposals currently on the table.
Covenants generally aim to enable restrictions on how coins are spent using two core concepts: introspection and forward data carrying.
Introspection allows scripts to examine different parts of a transaction to enforce specific spending rules. For instance, if you want a coin to only go to a certain address, introspection compares that address in the input script with the one in the transaction’s output. The more aspects of a transaction you can analyze, the stronger this capability becomes.
Forward data carrying builds on introspection, ensuring that certain data travels with each new covenant script iteration. This ensures that each successive script evaluation includes necessary information, allowing for complex spending conditions. The more powerful the introspection, the more versatile the data handling.
This discussion is just the tip of the iceberg. Over the coming weeks, we’ll explore major covenant proposals—especially those at a mature stage or gaining recent attention. These articles will provide a relatively comprehensive overview, although not every proposal strictly fits the traditional covenant model. However, they closely integrate with covenant concepts.
Upcoming topics will cover:
– CHECKTEMPLATEVERIFY
– CHECKSIGFROMSTACK
– TXHASH
– OP_VAULT
– CHECKCONTRACTVERIFY
– CAT
– TWEAKVERIFY
Keep an eye out as we delve deeper into each of these areas.
