Bitcoin Community Pushes for Underlying Software Changes, Potential First User-Led Soft Fork in Four Years
The Bitcoin community is driving changes to the underlying software, potentially bringing about the first user-led soft fork in four years. This change mainly concerns two important Bitcoin Improvement Proposals (BIP-119 and BIP-348), which aim to introduce new script functionalities—Covenants. These changes could significantly enhance Bitcoin’s smart contract capabilities and security.
Background: BlackRock: Bitcoin is Not a Risk Asset, Digital Gold Narrative Will Become Clearer
Supplementary Background: In Pursuit of Bitcoin’s Creator: A Reporter’s 15-Year Investigation into Satoshi Nakamoto
According to Blockspace, the grassroots Bitcoin community has started pushing for changes to the underlying Bitcoin software, a rare occurrence in over four years (previous significant changes to the protocol have been led by the core developer group). The community is supporting two Bitcoin Improvement Proposals (BIPs), namely BIP-119 (CTV) and BIP-348 (CSFS). These two proposals suggest new Bitcoin script writing methods that will enable Bitcoin to implement the “Covenants” functionality. These proposals could be implemented in the next Bitcoin soft fork.
To avoid confusion for readers who may not fully understand the relationship between Bitcoin Covenants and these specific BIPs, let us clarify:
Simply put, Covenants are a functional concept in the Bitcoin network, and the two BIPs mentioned here are different implementation proposals to achieve this functional concept.
What are Bitcoin Covenants?
Definition:
Covenants are a proposed mechanism in the Bitcoin protocol that allows for setting conditions or restrictions on how Bitcoin can be spent or transferred in a transaction. These conditions can span multiple transactions, restricting future spending methods, thus enhancing Bitcoin’s script capabilities.
Purpose:
1. Enhance Bitcoin’s smart contract capabilities, enabling more complex applications (such as loans, decentralized exchanges, vaults).
2. Improve security, preventing theft or misuse of funds.
3. Optimize network performance, such as reducing transaction fees or improving privacy.
At this point, we can clearly see that Covenants are a concept, and the BIPs mentioned—BIP-119 (CTV) and BIP-348 (CSFS)—are the specific implementations of this functional concept.
Current Status:
The Bitcoin mainnet currently does not officially incorporate any Covenant-related functionality, although discussions and proposals (such as BIP-119) have been ongoing for many years.
BIP 119: OP_CHECKTEMPLATEVERIFY (CTV)
A proposed Bitcoin opcode that allows a transaction output to specify a “template,” requiring subsequent spending transactions to match this template. Proposed by former Bitcoin Core contributor Jeremy Rubin, it has been in existence for over five years. It implements the “state carry” functionality by restricting funds to be spent only in pre-defined ways.
Use Cases:
1. Batch Payments: Reduces transaction fees.
2. Building decentralized exchanges (DEX) or loan agreements.
3. Implementing Vaults: Protect funds from theft.
CTV is a lightweight implementation of Covenants, focusing on output format restrictions without involving complex logic.
BIP 348: OP_CHECKSIGFROMSTACK (CSFS)
A proposed Bitcoin opcode that allows the verification of a signature against any message (not just the current transaction hash). It retrieves the signature, public key, and message from the stack and checks if the signature matches. Officially proposed by Jeremy Rubin and Brandon Black in November 2024. OP_CSFS is a powerful tool for implementing more flexible Covenants as it allows introspection of transaction inputs, i.e., examining the full contents or state of the signed transaction.
Specific Uses:
1. Covenants Implementation: OP_CSFS can be used to establish complex conditional logic, ensuring funds are only spent according to specific rules. For example, validators can check whether transaction inputs conform to a preset template or restriction.
2. Security Enhancements: Supports Vaults and decentralized protocols by preventing theft or unauthorized spending via signature verification.
3. Extensibility: When combined with other opcodes (such as OP_CAT), more complex smart contracts can be built.
When discussing Bitcoin’s Covenants and the BIP-119 (CTV) and BIP-348 (CSFS) proposals, it’s inevitable to mention OP_CAT.
BIP 347: OP_CAT
History:
Early Existence: OP_CAT was part of Bitcoin’s original script language, included by Satoshi Nakamoto in Bitcoin’s launch in 2009. It was initially designed to enhance script flexibility and support more complex logic.
Removal Reason (2010):
OP_CAT was removed (disabled) in 2010 to prevent potential security vulnerabilities and resource misuse. The specific issue was that without limitations, OP_CAT could be exploited by malicious users to generate infinitely long data (via recursive calls), leading to Denial of Service (DoS) attacks as Bitcoin nodes would need to process this data, increasing computational and storage overhead.
At that time, the Bitcoin scripting language was simplified, retaining only the most basic functions to ensure the protocol’s lightweight, security, and decentralization.
Definition and Purpose:
OP_CAT is an opcode in Bitcoin’s script language. While it is not a direct implementation of Covenants, it is a potential tool for constructing complex Covenant logic. Compared to the two opcodes mentioned earlier, OP_CAT is more general-purpose, suitable for data manipulation, but it needs to be combined with other opcodes to implement complex functionalities.
Current Status:
In recent years, the Bitcoin community has reopened discussions on the return of OP_CAT, previously appearing in the more community-playful BIP-420 proposal, but now formally merged into the bitcoin/bips repository under the BIP-347 number.
Progress:
According to Coindesk, in the past few weeks, many Western Bitcoin developers have expressed their support for CTV and CSFS on Twitter—this is undoubtedly a strong signal that, at least within the social media circles, part of the Bitcoin community is moving toward embracing these changes. Additionally, developers generally believe that the definitions of these two proposals are relatively “narrow.” Simply put, this means that once activated, the potential for user misuse is relatively low. The Bitcoin developer community has traditionally taken a cautious approach to changes in Bitcoin. For example, despite BIP-119 being shelved for nearly five years, CTV was still considered too radical not long ago.
The two proposals were co-initiated by Jeremy Rubin, who faced strong opposition in his earlier efforts to promote CTV—particularly criticism from prominent Bitcoin thought leaders with large followings, such as Adam Back and Jimmy Song. This criticism ultimately evolved into widespread discontent within the Bitcoin community, forcing Rubin to gradually withdraw from the Bitcoin space.
What, then, has contributed to this change? Recent advocacy for the OP_CAT opcode seems to have broadened the range of proposals considered “acceptable,” framing CTV and CSFS as relatively “conservative” options. Notably, most supporters of OP_CAT also support BIP 119 and BIP 348 (as well as most other proposals).
What can we expect next? First, discussions will continue. Developers are expected to further explore these proposals at several technical conferences, such as OPNEXT planned for April, BTC++ in July, and TABConf in October. Once developers reach a preliminary consensus, the actual activation of the soft fork will be handed over to miners, the community, and investors for final confirmation.
How to follow the progress of BIPs in community discussions and the soft fork process?
The answer is complicated! The Bitcoin technical community typically engages in in-depth discussions about these proposals. However, this is a seemingly obscure and circular discussion process.
In simple terms, the process for Bitcoin soft forks requires a rough estimate of the support levels from various stakeholders in Bitcoin, including developers, custodians, investors, and miners. The most intuitive support indicator usually comes from miners since they can signal their acceptance of codebase changes through the blocks they mine. Typically, Bitcoin Core requires a 95% support signal across blocks for a certain period before locking the update for activation.
However, there is currently no consensus on how to define “broad support.” Bitcoin consensus is always evolving. The reason miners are important signal providers is simply that they are a “countable” entity within the Bitcoin network. In other words, due to Bitcoin’s decentralized structure, it is challenging to measure overall consensus from a “visible” perspective.
Nevertheless, a Bitcoin NFT development company, Taproot Wizards, has illustrated the lengthy and complex process of Bitcoin soft forks using flowcharts, taking OP_CAT as an example. Interested readers can view this at https://www.quantumcats.xyz/bip-land. Here, we will attempt to summarize:
- The proposal is initially introduced and discussed in the Bitcoin developers’ mailing list.
- The discussion enters a broader community scope, leading to a long-term dilemma regarding the pros and cons of the proposal’s functionality. If progress cannot be made, it ends there.
- The grassroots community drafts the BIP on GitHub for the proposal.
- Developers start implementing the relevant code, needing to pass a long-term audit for bugs to proceed.
- After review by Bitcoin repository BIP editors and preliminary community approval, a formal BIP number is assigned.
- The proposal enters the Signet test network. Signet is a Bitcoin test network that allows developers to experiment with new features or code changes without affecting the main network. (Most new features might get permanently shelved at this step.)
- The proposal might enter the Liquid sidechain for testing.
- A PR is submitted to Bitcoin Core.
- The proposal enters the Bitcoin core code review and merging process, which is highly uncertain. A proposal can only move to the merging stage if it avoids most opposition and meets technical requirements (no severe bugs); the opinions of key developers (like Pieter Wuille) are often crucial, and their approval or disapproval can significantly impact the proposal’s fate.
- If the code audit is problem-free, it awaits the Bitcoin repository maintainers to merge the PR into the main project. Currently, there are five maintainers: Michael Ford (fanquake), Hennadii Stepanov (hebasto), Andrew Chow (achow101), Gloria Zhao (glozow), and Ryan Ofsky (ryanofsky).
- This is followed by potential disputes and discussions among different groups such as Bitcoin developers and miners.
- Choice of activation mechanism:
- Miner-Activated Soft Fork (MASF): Miners activate new rules through signaling (usually a 95% threshold), as in the default modes of BIP-9 or BIP-8. This is more stable but requires broad consensus and testing, thus taking longer.
- User-Activated Soft Fork (UASF): Node operators (users) forcibly activate new rules (like BIP-8’s “Lockinontimeout: True”), circumventing miner resistance, which carries potential chain fork risks and community divergence.
Previously reported by Wu, Bitcoin.org domain maintainer Cobra warned that the Bitcoin network might face a user-activated soft fork (UASF) initiated by anonymous developers outside Bitcoin Core in 2025, specifically referring to potential changes in BIP 119 mentioned in this article. Cobra believes these improvements could spark a division between “hardliners” and “improvers,” led by the grassroots community and pushed by non-Bitcoin Core developers.
It is understood that UASF (User-Activated Soft Fork) is a protocol upgrade method initiated by Bitcoin users, which forces protocol updates by upgrading node software, even if miners or other parties do not support it, thus also implying a risk of chain forks. However, there is no need to be overly concerned at this moment, as many issues remain unresolved. For example, will future soft forks only include CTV and CSFS? Will OP_CAT, which is often discussed alongside these opcodes, be considered? How will the actual activation process of the soft fork unfold? Will other stakeholders (such as Bitcoin miners) give it enough attention?
After all, as long as the consensus on BIPs is substantial enough, proposals driven by the grassroots community can also proceed in the form of miner-activated soft forks (MASF). Moreover, even in the case of UASF, there have been successful historical examples. UASF played a crucial role in the SegWit upgrade in 2017, where users successfully pushed for a soft fork, avoiding a hard fork and facilitating Bitcoin scalability.
- https://www.coindesk.com/tech/2025/03/17/developer-consensus-may-be-converging-on-a-bitcoin-soft-fork-proposal-blockspace
- https://www.quantumcats.xyz/bip-land
- https://github.com/bitcoin/bips
