Compiled by: Tao Zhu, Golden Finance; Author: Kyrian Alex, CoinTelegraph

Recently, with the resurgence of Bitcoin development and protocol discussions, the concept of so-called "covenants" has received renewed attention. Contracts enable and facilitate a range of applications, including new trustless and scalable layer 2 networks, fully non-custodial vaults with more complex spending logic, and more efficient payment channels. However, most paths to achieving this feature would require a soft fork of Bitcoin’s consensus rules, a process that is likely to spark debate within the community.

With the recent split of the consensus client into Core nodes and Knots nodes, the possibility of reaching agreement on such changes has become even less likely. Although Knots nodes have recently pushed for their own soft fork (i.e. BIP-110), they tend to be protocol inflexible and seem less supportive of implementing scaling solutions under the hood. The recent controversies caused by Bitcoin Core, both at the technical level and the governance level, have reduced the possibility of Bitcoin realizing the contract in the near future.

Celebrities such as Michael Thaler have also publicly advocated for the rigidity of the protocol, viewing enthusiastic and well-funded developers as the biggest threat to the protocol. Nonetheless, some minimal contract enforcement may be the most conservative approach to a trust-minimized Layer 2 network that gives the next billion users the right to data self-protection. If mainnet fees spike again in the future and spam issues are addressed, discussion around these proposals is likely to heat up again. This article will lay the foundation for readers to understand contracts. Subsequent articles will delve into each proposal.

To understand the contract proposal, you first need to master the basic verification process of Bitcoin transactions. Bitcoin's locking conditions are expressed in a stack-based, non-Turing-complete language called Bitcoin Script. The sender of a Bitcoin transaction specifies spending conditions by creating a so-called locking script (also known as scriptPubKey). When the recipient of the funds later wants to spend these Bitcoins, they must provide a corresponding unlocking script (also known as a scriptSig) that meets these conditions. Bitcoin's scripting language can express various verification conditions, such as verifying public key signatures, enforcing timelocks, verifying hash preimages, and combining spending conditions with propositional logic. An entity with the correct unlocking script can transfer Bitcoin to any location, i.e. bind the Bitcoin with any scriptPubKey. However, it cannot restrict where the funds go after providing the correct scriptSig.

This is exactly what contracts are designed to do. Contracts allow users to impose restrictions on how Bitcoin can be used in the future. The concept was first proposed by Gregory Maxwell in 2013 to improve Bitcoin’s scalability and flexibility. It was subsequently popularized by Möser, Eyal, and Sirer in 2016. Maxwell originally proposed using zk-SNARKs to limit spending. Since then, discussions have sprung up with a number of different proposals, some of which might even circumvent the need for a soft fork.

Basic contract (or precomputed contract) and general contract (or recursive contract)

The key distinction between contract proposals is between base contracts (or precomputed contracts) and universal contracts (or recursive contracts). In principle, the basic covenant only imposes restrictions on subsequent transactions. However, basic contracts can also be used to pre-define limited sequences of transactions by linking restricted addresses. While this allowed transaction sequence can be arbitrarily long or complex, it must be specified in advance.

Universal contracts can express recursive spending rules directly in Bitcoin script. This allows payout conditions to be reapplied indefinitely. For example, if Alice sends 1 Bitcoin to Bob, the basic contract can ensure that Bob can only send the funds to a specific address, or limit it to a certain number of times. However, under the universal contract, a UTXO worth 1 Bitcoin will maintain the same spending limit when Bob sends it to Steve, and when Steve transfers it further, without any predefined endpoint. While universal contracts offer greater flexibility, they face significant technical difficulties and are criticized by the community. Their implementation will also require significant updates to the protocol.

Proposed implementation plan of the Convention and its applications

Various implementations and discussions shape our understanding of how contracts enhance Bitcoin’s capabilities. In order to explore this topic clearly, it is necessary to divide the proposed changes into four categories:

• The opcode that fully implements the contract function. They impose spending limits directly on Bitcoin transactions. This includes OP_CHECKTEMPLATEVERIFY and SIGHASH_ANYPREVOUT.

• Opcodes used as auxiliary tools. These opcodes extend the expressive capabilities of Bitcoin scripts or data processing, but do not implement contract functionality by themselves unless used in conjunction with other opcodes. We will discuss OP_CHECKSIGFROMSTACK and OP_CAT.

• Opcode used for a specific application. We will consider OP_VAULT, OP_UNVAULT and OP_EVICT.

• Proposal to approximate contract behavior without soft fork. These proposals rely on existing consensus rules or cryptographic constructs in trust-minimizing infrastructure rather than new opcodes. We will discuss ColliderScript, Bitcoin PIPE, and front-end based contracts.

In the next article, we will start discussing the first type of contract proposals, starting with OP_CHECKTEMPLATEVERIFY - one of the most popular proposals to date.