Bitcoin Covenants

Recent discussions on Bitcoin protocol and development have brought renewed interest to the idea of covenants. Covenants have the potential to facilitate and enable many applications. new trustless and scalable layer 2sFully non-custodial Vaults, with more complex and efficient spending logic payment channels. Most paths for implementing the functionality of this feature require that you have a soft fork of Bitcoin’s consensus rulesThis would probably spark a debate in the community.

It is less likely to happen now that the clients have been split into Core nodes and Knots. Even though they recently called for a “soft-fork” of their own (namely BIP-110The Knots group tends to support protocol ossification, and is less interested in facilitating solutions for scaling on the bottom layer. Bitcoin Core’s recent controversy has been a source of much discussion, and it is not surprising. technical debate and in governanceThe prospect of Bitcoin adopting covenants in the near future is dimming.

Michael Saylor and other prominent figures have been criticized for their stance. publicly advocated for protocol ossificationIt is easy to see why zealous developers with a lot of money are the biggest threat. Nevertheless, some minimal Covenant implementation offers the conservative route to trust-minimized Layer-2s. This can give the privileges to self-custody for the next billion. Should mainnet fees spike again in the future and a resolution to the spam wars is found,  discussions around these proposals are likely to regain momentum. This article will help readers better understand covenants. We will dive deeper into each proposal in subsequent articles. 

It is important to understand the Bitcoin validation flow in order to fully grasp covenant proposals. The locking conditions for Bitcoin are written in an arbitrary, stack-based language that is not Turing-complete. Bitcoin Script. This language is used by the sender to specify spending requirements in a Bitcoin transaction. It’s called a locking script. scriptPubKey). If the beneficiary of the fund wants to later spend the outputs they will need the unlocking script. scriptSigThis is a valid Bitcoin script. Bitcoin’s scripting can include a wide range of conditions for validation. The language is capable of verifying public key signatures as well as timelocks. It also allows the combination of propositional logic and spending conditions. The entity that has the unlocking script in place can send the Bitcoin anywhere, or encumber it with any scriptPubKey. The correct scriptSig can still be used to restrict the location of funds sent.

This is what covenants are aiming to achieve. The covenants feature would enable users to set restrictions for future coin spending. The concept The first time that was introduced as Gregory Maxwell In 2013, Bitcoin was redesigned to increase its flexibility and scalability. Later, it was popularised by Möser, Eyal, and Sirer in 2016. Maxwell originally proposed Using zk SNARKs for spending restriction. The discussion has been flooded with different ideas since then. Some of them may even sidestep the need for a softer fork.

Basic (or precomputed) versus General (or recursive) covenants

In covenant proposals, the key distinction is between general and basic covenants. The basic covenants are only restricted to the following transaction. Basic covenants are also useful for defining a sequence of transactions by combining encumbered address chains. The sequence of transactions that are allowed can be as long or complicated as you like, but it has to be pre-specified. 

The general covenants will be able express recursive expenditure rules directly in Bitcoin Script. The condition can be applied indefinitely. A basic covenant, for example, could stipulate that Bob is only allowed to send funds from Alice’s account or can encumber them in a certain number of steps. A general covenant would allow the UTXO to retain its restrictions even if Bob sent it on to Steve and then again when Steve transferred it, as long as there was no pre-defined ending point. General covenants offer more flexibility, but they are also subject to significant technical challenges and are not well received by the community. They would also need to be implemented. major protocol updates.

The Proposed Covenant Implementations, and their Applications

Many implementation proposals and discussions have contributed to our current understanding of the potential benefits that covenants may bring Bitcoin. For clarity, we can divide the four types of proposed changes:

• These Opcodes fully implement covenant functionalities. These Opcodes directly restrict Bitcoin spending. They directly impose spending restrictions on Bitcoin transactions. OP_CHECKTEMPLATEVERIFY You can also find out more about the following: SIGHASH_ANYPREVOUT.
• They are used to support other tools. They are used to enhance the expression of Bitcoin scripts or data processing, but they do not provide covenant functionality without combining them with another opcode. This category will cover OP_CHECKSIGFROMSTACK You can also find out more about the following: OP_CAT.
• We consider that specialized applications require Opcodes. Consider OP_VAULT, OP_UNVAULT You can also find out more about the following: OP_EVICT.
• These proposals approximate covenant behaviour without the need for a hard fork. Instead of new opcodes, these rely on cryptographic constructs that are part of existing consensus rules and infrastructures with minimal trust. We will be discussing ColliderScript (a cryptographic script), Bitcoin PIPE (a protocol for transferring bitcoins) and FE-based agreements. 

In our next article we will commence our discussion of the first category of covenant proposals by covering OP_CHECKTEMPLATEVERIFY — one of the most popular proposals so far.