Bitcoin Covenants Part 1: Unlocking Advanced Transaction Control Through Novel Spending Restrictions
Twelve different proposals have emerged to address one absent capability in Bitcoin Script. Cointelegraph Research provides a comprehensive analysis.
In recent times, the notion of covenants has garnered fresh interest as discussions surrounding Bitcoin protocol development have experienced a revitalization. The implementation of covenants would open doors to numerous applications, such as innovative trustless and scalable second-layer solutions, completely non-custodial vaults featuring sophisticated spending mechanisms, and payment channels with enhanced efficiency. That said, the majority of approaches toward implementing this capability would necessitate a soft fork modification to Bitcoin's consensus framework, a move that would almost certainly trigger considerable discussion among community members.
Given the recent expansion of consensus clients to include both Core and Knots nodes, achieving consensus on such modifications has become increasingly challenging. Despite recently advocating for their own soft-fork proposal, specifically BIP-110, proponents of Knots generally favor protocol ossification and seem less inclined to support scaling enhancements at the base layer. The recent disputes that have surrounded Bitcoin Core, encompassing both technical considerations and governance matters, are reducing the likelihood of covenant implementations being adopted on Bitcoin in the near term.
Notable personalities including Michael Saylor have also voiced support for protocol ossification in public forums, characterizing overly enthusiastic, well-resourced developers as the primary risk to the protocol's stability. Nevertheless, implementing some form of minimal covenant functionality likely represents the most cautious pathway toward trust-minimized second-layer networks, which have the potential to extend self-custody capabilities to the next billion users. Should transaction fees on the mainnet surge once more in the future and a solution to the spam controversies emerge, conversations regarding these proposals will probably gain renewed traction. Throughout this article, we will establish fundamental knowledge for our readers to comprehend covenants. In subsequent installments, we will examine specific proposals in greater detail.
Comprehending covenant proposals requires understanding 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 using this language through the creation of what is called a locking script (alternatively referred to as scriptPubKey). Subsequently, when the receiver of these funds wishes to spend the outputs, they are required to supply the matching unlocking script (alternatively called scriptSig) that satisfies these requirements. Bitcoin's scripting framework supports expressing various validation criteria. It has the capability to verify signatures from public keys, implement timelocks, verify preimages of hashes, 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 using any arbitrary scriptPubKey. Nevertheless, it lacks the capability to impose limitations on the destination of funds once the proper scriptSig has been supplied.
This particular capability is what covenants seek to introduce. Covenants would grant users the power to establish constraints on future spending of coins. Gregory Maxwell introduced the concept as far back as 2013 with the goal of enhancing Bitcoin's scalability and adaptability. The idea gained wider recognition through the work of Möser, Eyal, and Sirer in 2016. Maxwell's original proposal involved utilizing zk-SNARKs to enforce spending constraints. In the years following, the discourse has witnessed a proliferation of alternative proposals, with some potentially bypassing the need for a soft fork altogether.
Basic (or precomputed) versus General (or recursive) covenants
A fundamental differentiation among covenant proposals exists between basic (or precomputed) and general (or recursive) covenant types. Fundamentally, basic covenants establish constraints solely on the immediately following transaction. Nonetheless, through the sequential linking of encumbered addresses, basic covenants can also be employed to predefine a finite series of transactions. Although this series of allowable transactions may be arbitrarily lengthy or intricate, it requires advance specification.
General covenants would possess the ability to articulate recursive spending regulations directly embedded within Bitcoin Script. This functionality enables a spending condition to be perpetually reapplied without limitation. As an illustration, if Alice transferred 1 BTC to Bob, a basic covenant mechanism could guarantee that Bob is limited to sending the funds to a designated address or encumbering them for a predetermined number of transaction steps. With a general covenant framework, however, the UTXO containing 1 BTC would preserve its identical spending constraints when Bob transfers it to Steve, and once more when Steve passes it onward, without any predefined conclusion. While general covenants would provide enhanced flexibility, they encounter substantial technical challenges and receive skeptical reception from the community. Their deployment would additionally necessitate significant protocol modifications.
Proposed Covenant Implementations and Their Applications
Numerous implementation proposals and ongoing debates have influenced our comprehension of the ways covenants could augment Bitcoin's capabilities. For the purpose of navigating this subject with clarity, it becomes essential to categorize the proposed modifications into four distinct groups:
- Opcodes that comprehensively implement covenant capabilities. They directly enforce spending constraints on Bitcoin transactions. This encompasses OP_CHECKTEMPLATEVERIFY and SIGHASH_ANYPREVOUT.
- Opcodes that function as auxiliary instruments. These expand the expressiveness of Bitcoin script or enhance data manipulation capabilities but fail to implement covenant functionality in isolation without combination with additional opcodes. Within this classification, we will examine OP_CHECKSIGFROMSTACK and OP_CAT.
- Opcodes designed for particular use cases. We consider OP_VAULT, OP_UNVAULT and OP_EVICT.
- Proposals that replicate covenant behavior while avoiding a soft fork. These depend on cryptographic frameworks operating within current consensus regulations or trust-minimized infrastructure as opposed to introducing new opcodes. In this classification, we will examine ColliderScript, Bitcoin PIPE and FE-based covenants.