For the first time in four years, Bitcoin may be facing a "User-Activated Soft Fork" (UASF)?

Original Article Title: "For the First Time in Four Years, Bitcoin Could See a 'User-Activated Soft Fork'?"

Original Article Author: GaryMa, Wu Shuo Blockchain

According to a Blockspace report, the Bitcoin base layer community is beginning to drive changes to Bitcoin's underlying software, which is a rare event in over four years (previously, major underlying changes were mostly driven by the core developer group).

The emerging grassroots support this time is for two Bitcoin Improvement Proposals (BIPs), namely BIP-119 (CTV) and BIP-348 (CSFS). These two proposals introduce a new way to write Bitcoin scripts, enabling Bitcoin to achieve "Covenants" functionality. These two proposals may be implemented in the next Bitcoin soft fork.

To help readers who may temporarily not understand Bitcoin's Covenants and the specific relationship of these BIP proposals, let's clarify here:

Simply put, Covenants are a functional concept in the Bitcoin network, while the two mentioned BIPs 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 conditions or restrictions to be set in transactions, specifying how Bitcoin can be spent or transferred. These conditions can span multiple transactions, restricting future spending, thereby enhancing Bitcoin's script capabilities.

Role:

· Enhance Bitcoin's smart contract capabilities, supporting more complex applications (e.g., loans, decentralized trading platforms, custody services).

· Improve security to prevent fund theft or misuse.

· Optimize network performance, such as reducing transaction fees or enhancing privacy.

From this, we can roughly understand that Covenants are a concept, and the BIP-119 (CTV) and BIP-348 (CSFS) mentioned in this article are specific implementations of this Covenant functionality.

Current Status:

The Bitcoin mainnet currently does not formally integrate any Covenant-related functionality, although related discussions and proposals (such as BIP-119) have been advancing for years.

BIP 119: OP_CHECKTEMPLATEVERIFY (CTV)

An proposed Bitcoin opcode that allows a transaction output to specify a "template," requiring subsequent spending transactions to match that template.

Proposed by former Bitcoin Core contributor Jeremy Rubin, it has existed for over five years. By restricting funds to be spent only in a predefined way, it achieves "state carrying" functionality.

Use cases include:

· Creating batch payments to reduce transaction fees. Building decentralized exchange (DEX) or lending protocols.

· Implementing Vaults to protect funds from theft.

· CTV is a lightweight implementation of Covenants, focusing on output format restrictions rather than involving complex logic.

BIP 348: OP_CHECKSIGFROMSTACK (CSFS)

A proposed Bitcoin opcode that allows verifying a signature's validity for any message, not just the hash of the current transaction. It retrieves the signature, public key, and message from the data stack and checks if the signature matches.

Formally proposed by Jeremy Rubin and Brandon Black in November 2024.

OP_CSFS is a powerful tool for implementing more flexible Covenants as it enables "introspection" on transaction inputs, allowing verification of the full content or state of a signature transaction.

Specific applications:

· Covenant Implementation: OP_CSFS can be used to create complex conditional logic to ensure funds are spent according to specific rules. For example, validators can check if a transaction input complies with a preset template or restriction.

· Security Enhancements: Supporting Vaults and decentralized protocols to prevent theft or unauthorized spending through signature verification.

· Scalability: Combined with other opcodes (such as OP_CAT), it can be used to build more complex smart contracts.

When discussing Bitcoin Covenants and the BIP-119 (CTV) and BIP-348 (CSFS) proposals, OP_CAT is definitely a key part of the conversation.

BIP 347: OP_CAT

History:

Early Existence: OP_CAT is part of the original Bitcoin Script language, included by Satoshi Nakamoto upon 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 abuse.

· Specific Issue: Without restrictions, OP_CAT could be used by malicious users to generate infinitely long data (through recursive calls), leading to a Denial of Service Attack, as Bitcoin nodes would need to process this data, increasing computational and storage costs.

· At that time, the Bitcoin script language was simplified, retaining only the most basic functionality, ensuring protocol lightness, security, and decentralization.

Definition and Purpose:

OP_CAT is a Bitcoin Script operation code (Opcode). It is not a direct Covenant implementation but is a potential tool for building complex Covenant logic. Compared to the two aforementioned opcodes, OP_CAT is more general-purpose, suitable for data operations, but it needs to be combined with other opcodes to achieve complex functionality.

Current Status:

The Bitcoin community has recently been discussing the reintroduction of OP_CAT. Previously appearing in the form of the somewhat whimsical BIP-420 proposal, it has now been formally merged into the bitcoin/bips repository under the BIP-347 number.

How the Progress Is Going

According to Coindesk reports, over 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 in the social media sphere, part of the Bitcoin community is moving towards accepting these changes.

Furthermore, developers generally believe that the definitions of these two proposals are "narrow." In simple terms, this means that once activated, there is a low likelihood of being accidentally abused by users. The Bitcoin developer community has always been cautious about changes to Bitcoin. For example, although BIP 119 has been postponed for nearly five years, CTV was recently seen as too aggressive and unsuitable for activation.

The co-founder of these two proposals, Jeremy Rubin, had previously faced strong opposition for his efforts to promote CTV—especially from some influential Bitcoin thought leaders with large followings, such as Adam Back and Jimmy Song. The various criticisms eventually evolved into widespread dissatisfaction within the Bitcoin community, forcing Rubin to eventually fade out of the Bitcoin space.

So, what led to this change? Recent advocacy for the OP_CAT opcode seems to have expanded the perceived scope of what is "acceptable" in Bitcoin proposals, positioning CTV and CSFS as relatively "conservative" options. It is noteworthy that most supporters of OP_CAT also support BIP 119 and BIP 348 (as well as most other proposals).

What can we expect next? Firstly, the discussion will continue. Developers are expected to further explore these proposals at several technical conferences, such as the planned OPNEXT in April, BTC++ in July, and TABConf in October. Once developers reach 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 up on BIPs' community discussion progress/soft fork process?

The answer is quite challenging!

Bitcoin's technical community usually engages in in-depth discussions on these proposals. However, this is a seemingly opaque and cyclical discussion process.

In essence, the Bitcoin soft fork process requires a rough estimation of the level of support from various Bitcoin stakeholders, including developers, custodians, investors, and miners. The most direct support indicator usually comes from miners, as they can signal approval of codebase changes by including signals in the blocks they mine. Typically, Bitcoin Core requires a signaling support from 95% of blocks over a period of time before proceeding to lock in the update for activation.

However, there is currently no consensus on how to define "widespread support," and Bitcoin consensus is always evolving. Miners are crucial signal providers simply because they are a "countable" entity in the Bitcoin network. In other words, due to Bitcoin's decentralized structure, it is challenging to visually measure overall consensus.

Nevertheless, Taproot Wizards, a development company famous for Bitcoin NFTs, has unveiled the long and complex process of a Bitcoin soft fork using OP_CAT as an example in a flowchart format. Readers interested in this can refer to https://www.quantumcats.xyz/bip-land for a detailed view; here, we will attempt to summarize:

BIP Proposal Lifecycle | The Long and Complex Journey of a Bitcoin Soft Fork

1. The proposal is initially brought up and discussed on the Bitcoin developers mailing list.

2. It moves on to a broader community discussion, delving into the long-standing debate of the pros and cons of the proposal; if further progress cannot be made, it may end here.

3. The grassroots community drafts a BIP proposal on Github.

4. Developers begin working on the related code implementation, which must pass a thorough audit to proceed.

5. After review by the Bitcoin repository BIP editors and initial community acceptance, the proposal is assigned a formal BIP number.

6. It moves on to the Signet test network. Signet is a Bitcoin test network that allows developers to experiment with new features or code changes without impacting the mainnet. (Many new features may end up permanently stuck at this stage.)

7. It may undergo testing on the Liquid sidechain.

8. A PR is submitted to Bitcoin Core.

9. It enters the Bitcoin Core code review and proposal merge process, which is highly uncertain. Only when most objections are addressed and technical requirements are met (no major bugs) does the proposal stand a chance of moving towards the merge phase; the opinions of key developers (such as Pieter Wuille) often hold significant weight, and their approval or rejection can greatly impact the fate of the proposal.

10. If the code review goes smoothly, the proposal waits for 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), Ryan Ofsky (ryanofsky).

11. Further potential controversies and discussions among different groups in the Bitcoin community, including developers and miners.

12. Activation Mechanism Selection:

a. Miner-Activated Soft Fork (MASF): New rules are activated by miners through signaling (usually a 95% threshold), following the default mode of BIP-9 or BIP-8. This method is more stable but requires coordination for widespread consensus and testing, hence taking longer;

b. User-Activated Soft Fork (UASF): A protocol upgrade method initiated by Bitcoin users to enforce new rules (such as BIP-8's "Lockinontimeout: True"), bypassing miner resistance, with potential chain split risk and community division.

Conclusion

Previously reported by Wu, Bitcoin.org domain maintainer Cobra warned that the Bitcoin network might, in 2025, see a user-activated soft fork (UASF) initiated by an anonymous developer outside of Bitcoin Core, essentially referring to the potential changes in BIP 119 mentioned in this article. Cobra believes that these improvements could trigger a divide between the "status quo camp" and the "upgrade camp," led by the grassroots community and propelled by non-Bitcoin Core developers.

Understood to be a protocol upgrade method initiated by Bitcoin users, User-Activated Soft Fork (UASF) enforces protocol updates through upgraded node software, even if miners or others do not support it, thus implying a chain split risk. Of course, there is no need to be overly concerned at the moment, as many things are still undecided. For example, will future soft forks only include CTV and CSFS? Will OP_CAT, often discussed alongside this set of 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?

Ultimately, as long as there is sufficient consensus on BIPs, proposals driven by the grassroots community can also take the form of miner-activated soft forks (MASF). Furthermore, even with UASF, there have been successful cases in history. UASF played a crucial role in the 2017 SegWit upgrade, where users successfully drove a soft fork, avoided a hard fork, and promoted Bitcoin scalability.

Reference Links:

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

Original Article Link