Bitcoin Covenants Part 1: Understanding Advanced Transaction Restrictions and Their Potential Impact on the Bitcoin Protocol
The absence of one critical capability in Bitcoin Script has generated a dozen different implementation proposals. Cointelegraph Research provides a comprehensive examination.
In recent times, the notion of what are known as covenants has garnered fresh interest as Bitcoin's development community and protocol conversations have experienced a revival. The implementation of covenants could unlock and support a diverse array of use cases, such as innovative trustless and scalable second-layer solutions, completely non-custodial vault systems featuring advanced spending mechanisms, and more streamlined payment channel architectures. Nevertheless, the majority of approaches to deploying this capability would necessitate a soft fork modification to Bitcoin's consensus framework, a procedure that would almost certainly trigger substantial discussion among community members.
Given the recent expansion of consensus client diversity to include both Core and Knots implementations, achieving consensus on such a modification has grown increasingly challenging. Despite their recent advocacy for their own soft-fork proposal, specifically BIP-110, the Knots faction generally promotes protocol ossification and seems less inclined to support scaling mechanisms at the base layer level. The recent disputes that have surrounded Bitcoin Core, encompassing both technical considerations and governance questions, are reducing the likelihood of covenant deployments on Bitcoin in the near term.
Influential personalities including Michael Saylor have likewise openly championed protocol ossification, characterizing overly enthusiastic, well-resourced developers as the primary danger to the protocol's integrity. Nevertheless, implementing some minimal form of covenants probably represents the most prudent route toward trust-minimized second-layer networks, which have the potential to extend the benefits of self-custody to the next billion users. Should transaction fees on the mainnet surge once more in the future and a solution to the spam conflicts emerges, conversations surrounding these proposals will likely gather renewed energy. Within this article, we will establish some foundational concepts for our audience to comprehend covenants. In subsequent installments we will conduct an in-depth examination of specific proposals.
To comprehend covenant proposals properly, one must first understand the fundamental validation process for Bitcoin transactions. Bitcoin's locking mechanisms are written in a stack-oriented, non-Turing-complete programming language known as Bitcoin Script. The originator of a Bitcoin transaction defines the spending requirements in this language by constructing what is called a locking script (alternatively referred to as scriptPubKey). When the receiver of these funds subsequently wishes to spend the outputs, they are required to supply the matching unlocking script (alternatively referred to as scriptSig) that satisfies these requirements. Bitcoin's scripting language possesses the ability to express numerous validation requirements. It has the capacity to verify signatures from public keys, implement timelocks, verify preimages of hash functions, and merge spending requirements using propositional logic. Any party possessing the appropriate unlocking script has the ability to transfer the Bitcoin to any desired destination, meaning they can encumber them with any arbitrary scriptPubKey. What it cannot do, however, is impose limitations on the destination of funds following the provision of the correct scriptSig.
This particular capability represents what covenants seek to introduce. Covenants would grant users the power to establish restrictions on the future spending of coins. This concept was first introduced by Gregory Maxwell as far back as 2013 with the goal of enhancing the scalability and adaptability of Bitcoin. It subsequently gained broader recognition through the work of Möser, Eyal, and Sirer in 2016. Maxwell's original proposal involved utilizing zk-SNARKs to enforce spending limitations. From that point forward, the discourse has witnessed a proliferation of various proposals, reaching a point where some approaches may circumvent the need for a soft fork entirely.
Basic (or precomputed) versus General (or recursive) covenants
A fundamental differentiation among covenant proposals exists between basic (or precomputed) and general (or recursive) covenant structures. In essence, basic covenants exclusively enforce restrictions on the immediately following transaction. Nevertheless, through the linking together of encumbered addresses, basic covenants can additionally be employed to establish a predetermined sequence of transactions ahead of time. Although this chain of authorized transactions can be of arbitrary length or complexity, it requires advance specification.
General covenants would possess the capability to articulate recursive spending regulations directly embedded within Bitcoin Script. This capability permits a spending condition to be reapplied perpetually. As an illustration, if Alice transferred 1 BTC to Bob, a basic covenant mechanism could guarantee Bob is limited to sending the funds exclusively to a designated address or encumbering it for a predetermined number of stages. With a general covenant, conversely, the UTXO valued at 1 BTC would maintain its identical spending constraints when Bob transfers it to Steve, and once more when Steve passes it along further, without any predefined termination point. While general covenants would provide enhanced flexibility, they encounter substantial technical obstacles and receive critical scrutiny from the community. Their deployment would additionally necessitate significant protocol modifications.
Proposed Covenant Implementations and Their Applications
Numerous implementation proposals and ongoing debates have informed our comprehension of how covenants might augment Bitcoin's capabilities. To approach this subject with clarity, it becomes essential to categorize the proposed modifications into four distinct groups:
- Opcodes that completely implement covenant capabilities. They directly establish spending limitations on Bitcoin transactions. This category encompasses OP_CHECKTEMPLATEVERIFY and SIGHASH_ANYPREVOUT.
- Opcodes that function as auxiliary tools. These expand the expressive power of Bitcoin script or data manipulation capabilities but do not provide covenant functionality unless paired with other opcodes. Within this category, we will examine OP_CHECKSIGFROMSTACK and OP_CAT.
- Opcodes designed for specific applications. We will consider OP_VAULT, OP_UNVAULT and OP_EVICT.
- Proposals that replicate covenant functionality without requiring a soft fork. These depend on cryptographic frameworks within the existing consensus regulations or trust-minimized infrastructure instead of introducing new opcodes. Within this category, we will examine ColliderScript, Bitcoin PIPE and FE-based covenants.