Elevating Bitcoin: Exploring BIP-420’s Vision for Enhanced Functionality
A BIP (Bitcoin Improvement Proposal) is a design document for introducing features or information to Bitcoin. A BIP must contain a concise technical specification of the feature and a rationale for it. This is the standard way of conveying ideas, as Bitcoin has no formal structure.
Why are BIPs needed?
Bitcoin is a software program running on a digital protocol. It is constantly being updated – bugs are fixed, algorithms are made more efficient, the code is simplified, compatibility with other software is maintained, and new features are added.
The first cryptocurrency has no central governing body or organization responsible for its development – it is a decentralized, open-source system. Therefore, decisions about updates are made by a community of independent developers, and BIPs serve as a way to formalize the process of updating the Bitcoin code and make it transparent.
Each proposal, formatted as a BIP, is assigned a sequential number. The framework is primarily used for updating the protocol or making significant changes. Not every change to the Bitcoin code requires going through this procedure, such as in the case of user interface design changes or bug fixes.
As you probably know, Bitcoin is not controlled by any single organization or company, and therefore there is no official structure that could propose improvements to the Bitcoin protocol or code. Any developer or anyone from anywhere in the world can propose a BIP. And the entire Bitcoin community – users, miners, developers and investors – will vote and decide whether to implement this proposal or not.
When did the process of updating Bitcoin code using BIPs begin?
The first Bitcoin Improvement Proposal – BIP1 – appeared in 2011, submitted by the British-Iranian programmer Amir Taaki. He was inspired by the PEP proposal used to improve the Python programming language. The BIP process is also similar to the RFC used to improve the internet. The list of BIPs presented to the Bitcoin community so far can be found here.
Types of BIPs
There are three main types of BIPs:
Standards Track BIPs – these types of BIPs involve changes to the network protocol, blockchain, or transaction validation method. Additionally, they must affect the compatibility between two versions of a BIP or Bitcoin. This type of BIP certainly requires community consensus. An example is BIP 91.
Informational BIPs – these BIPs cover design issues, general guidelines, and auxiliary information. Informational BIPs, as the name suggests, are intended for informational purposes only and may be taken seriously or ignored by the community. An example is BIP 32.
Process BIPs – these types of BIPs describe or propose changes to the process. They are similar to standards track BIPs and require community consensus. They cannot be ignored, but unlike standards track BIPs, they are intended for application outside of the Bitcoin protocol. An example is BIP 2.
Bitcoin Improvement Proposal (BIP) Lifecycle
Depending on the type of BIP, community consensus may be required. But even before this consensus, when any of the aforementioned BIP types are submitted, it goes through various statuses such as drafted, reviewed, accepted, rejected, or replaced.
How are BIPs proposed and accepted?
The process of accepting a Bitcoin improvement proposal is divided into several stages and is only activated after reaching community consensus.
Typically, a BIP starts with an informal proposal, which is put forward by a member of the community through various communication channels, such as the IRC application-level protocol or the Slack messenger. The idea is then publicly discussed. Anyone can propose an idea for a BIP, regardless of their credentials or reputation.
Once the proposal gains significant community support, the author can move to the next stage – turning the idea into a BIP. For this, the proposal must contain a brief technical specification and a justification for the new feature.
A special editor acts as a BIP auditor, who is also responsible for administering the update. They help to format the proposal in the style and format of a BIP, and also ensure that the proposal does not duplicate existing ideas.
After the editor deems the proposal ready, the draft is assigned an official number, for example, BIP-0119. A BIP can only address one specific feature to avoid complicating the discussion.
Once the BIP draft is submitted to a dedicated repository, the proposal is “transparently” processed, and anyone can track the progress and test results. Each draft has a specific status: accepted, deferred, rejected, or withdrawn by the community.
The diagram below illustrates the typical BIP lifecycle, showing the various status changes:
BIP Examples
Segregated Witness (also known as SegWit): SegWit, or BIP 141, was proposed in 2015 by some Bitcoin Core developers. Its goal is to increase the capacity of the Bitcoin network and resolve the issue of transaction malleability. It is a soft fork that requires a majority (95%) of miners to signal the upgrade within a two-week period.
In simple terms, SegWit means separating the witness signatures from the transactions. Imagine Bitcoin blocks as train cars that carry new passengers and their luggage every 10 minutes. If you want to transport more passengers in the same train car, you can start sending the passengers’ luggage separately. This way, there is more space for the passengers in the car.
Similarly, for each 1 MB Bitcoin block generated every 10 minutes, a transaction and its witnesses (i.e., signatures) are included. If we start sending the signatures separately, more transactions can be processed within the 1 MB block.
BIP 91: BIP 91, like BIP 141, is also a SegWit soft fork, which was introduced by Bitmain engineer James Hilliard in May 2017.
BIP 148 (also known as UASF-User Activated Soft Fork): BIP 148 is another user-activated soft fork for SegWit, proposed by an anonymous author named Shaolin Fry in March 2017. It provides a unique way to scale Bitcoin. It requires 50% or more of Bitcoin full node users, such as exchanges and miners, to upgrade their software on a predetermined flag day.
SegWit2x (also known as NYA): SegWit2x is a peculiar derivative name that combines two scaling solutions – SegWit and an increase in the block size to 2 MB.
User Activated Hard Fork (also known as UAHF/Bitcoin ABC/Bitcoin Cash BCC): Bitcoin ABC is the name of the open-source software that allows the use of Bitcoin. It is designed to facilitate a hard fork to increase the Bitcoin block size limit. The “ABC” acronym stands for “Adjustable Blocksize Cap”. Bitcoin ABC is a fork of the Bitcoin Core software project.
This solution is also referred to as a user-activated hard fork, but it should be called a “miner-activated hard fork” (aka MAHF) because it was proposed and supported by a minority group of miners as a contingency plan in case BIP 148 (aka UASF) was activated on August 1, 2017. However, this group of miners, users, and developers later went against the initially agreed-upon SegWit idea (or BIP 91, or SegWit2x) and decided to fork Bitcoin into Bitcoin Cash on August 1, 2017, at 12:20 p.m. UTC.
BIP-420 Proposal Aims to Develop a New Protocol for Smart Contracts on Bitcoin
The BIP-420 proposal aims to develop a new protocol that would allow for the execution of smart contracts on the Bitcoin network without the need for third-party solutions. BIP-420 proposes the use of OP_CAT as the mechanism to enable such Bitcoin-based smart contracts.
What is OP_CAT? OP_CAT is a protocol designed for executing smart contracts on Bitcoin. It would allow the Bitcoin network to be used for entering into and fulfilling multilateral agreements between parties. Why is this important? This could lead to increased use of Bitcoin as a tool for commercial agreements, making it a more versatile medium of exchange.
In late April 2024, Udi Wertheimer, the co-founder of Taproot Wizards and a proponent of OP_CAT, announced that the OP_CAT proposal had officially received a BIP number – BIP-420. “Today, after much anticipation, the OP_CAT proposal has officially received a BIP number. Introducing BIP-420,” Wertheimer posted. “BIP-420 activates covenants in Bitcoin, enabling smart contracts, secure bridges, on-chain trading, zk-proof verification, and much more. This is an important step in making Bitcoin magical again,” he added.
The BIP-420 proposal supports Bitcoin-based contracts, providing for smart contracts, secure bridges, on-chain transactions, and zk-proof verification. The OP_CAT opcode is expected to simplify and expand Bitcoin’s functionality, including making decentralized protocols more practical and supporting enhanced multisig configurations.
OP_CAT was initially included as one of the first opcodes in Bitcoin. However, due to concerns about creating potentially vulnerable scenarios, the anonymous creator Satoshi Nakamoto disabled it along with several other opcodes in 2010. The BIP-420 proposal, written by Ethan Heilman and Armin Sabouri, aims to reintroduce OP_CAT into Bitcoin through a backwards-compatible soft fork by “redefining the OP_SUCCESS126 opcode.” This utilizes the same opcode value as the original OP_CAT, with the goal of avoiding any potential confusion from using a different opcode value. The proposal is focused solely on reintroducing the opcode without changing other aspects of script constraints.
The viability of a soft fork for OP_CAT depends on a combination of technical considerations, security concerns, and community consensus. Without widespread consensus and clear evidence of its safety and utility, the implementation of OP_CAT remains uncertain.
On May 1, 2024, OP_CAT, also known as BIP-420, was launched on the official Bitcoin testnet “SIGNET.” This will allow developers to create advanced OP_CAT applications using CatVM and conduct real-time testing on the official testnet. Previously, the “signet” was the Bitcoin testnet created specifically for developers wishing to test their software. There are no miners on “signet,” and “signet” operators create a block on average every 10 minutes without the need for proof-of-work. For those familiar with the Ethereum testnet, Bitcoin’s “signet” is similar to Ethereum’s “sepolia” network.
After Wertheimer and others began circulating the BIP-420 proposal, some claimed that the proposal was “unofficial.” “This is not official,” commented one user in Wertheimer’s thread. Bitcoin developer Luke Dashjr also dismissed the BIP as “fake news,” but did not provide detailed reasons for such a consideration.
“Fake news. It shows that the movement for OP_CAT is not in good faith,” wrote Daschjr, responding in several posts to X posts.
As the debates around BIP-420 continue, the broader implications for the evolution of Bitcoin are becoming clearer. While some perceive the reintroduction of OP_CAT as a technological achievement, others are more skeptical, concerned about the motivations and potential security risks. This divide underscores the ongoing tensions within the Bitcoin community. It has reignited since the block size wars and was further exacerbated by the introduction of Ordinals. Currently, Runes and significantly high network fees are causing even more heated debates. The outcome of these debates remains uncertain.
Following the accusations of “fake news,” Wertheimer addressed the community with another post on X, explaining the assignment of the number. “BIP-420 was NOT self-assigned by its authors. The BIP was written by Ethan Heilman and Armin Sabouri, and neither of them assigned the number, so BIP-420 was NOT self-assigned,” Wertheimer emphasized. “BIP-420 was assigned by the Bitcoin community due to the growing interest in the discussion of the OP_CAT update.”
Wertheimer also explained the absence of the BIP in the BIP repository. He stated:
To maintain decentralization, multiple copies of BIP documents exist across the internet. It may take some time for these copies to be updated after a new BIP number is assigned. One of the popular BIP document repositories was previously maintained by former Bitcoin contributor Luke Daschjr, but Luke has informed the Bitcoin community that he no longer has the time to support this repository.