Hopefully adding more usability, Bitcoin could usher in its first user-led soft fork in four years?
Reprinted from panewslab
03/20/2025·2MCompiled by: GaryMa Wu said blockchain
According to Blockspace, the Bitcoin grassroots community is beginning to promote changes in Bitcoin’s underlying software, which is a rare thing in more than four years (previously major underlying changes were driven by the core developer group).
This time, the grassroots support is two Bitcoin improvement proposals (BIP), namely BIP-119 (CTV) and BIP-348 (CSFS). These two proposals propose new ways to write Bitcoin scripts, which will enable Bitcoin to implement the functionality of "Covenants". Both proposals may be implemented in Bitcoin’s next soft fork.
In order to avoid some readers not being able to understand the relationship between Bitcoin’s Covenants and these specific BIP solutions for the time being, here we clarify:
Simply put, Covenants is a functional concept in the Bitcoin network, and the two BIPs mentioned in the article are different implementation solutions for this functional concept.
What are Bitcoin’s Covenants?
definition:
Covenants are the mechanism proposed in the Bitcoin protocol that allows conditions or restrictions to be set in transactions that stipulate how Bitcoin is spent or transferred. These conditions can span multiple transactions, limiting future spending methods, thereby enhancing Bitcoin’s scripting capabilities.
effect:
· Improve the smart contract capabilities of Bitcoin and support more complex applications (such as loans, decentralized exchanges, vaults).
· Enhance security and prevent funds from being stolen or misused.
· Optimize network performance, such as reducing transaction fees or increasing privacy.
Here we can probably understand that Covenants is a concept, and the BIP-119 (CTV) and BIP-348 (CSFS) mentioned in this article are the specific implementation of the functional concept of Covenants.
Current status:
The Bitcoin mainnet currently does not officially integrate any Covenants-related features, although related discussions and proposals (such as BIP-119) have been advanced for many years.
BIP 119: OP_CHECKTEMPLATEVERIFY (CTV)
A proposed Bitcoin opcode allows transaction output to specify a "template" and requires that subsequent transaction outputs must match the template.
Proposed by former Bitcoin core contributor Jeremy Rubin, it has been around for more than five years. It realizes the "status carry" function by restricting funds to be spent in a predefined manner.
Application scenarios include:
· Create Batch Payments to reduce transaction fees. Build a decentralized exchange (DEX) or loan agreement.
· Implement Vaults to protect funds from theft.
· CTV is a lightweight implementation of Covenants that focuses on output format limitations without involving complex logic.
BIP 348: OP_CHECKSIGFROMSTACK (CSFS)
A proposed Bitcoin opcode that allows verification that a signature is valid for an arbitrary message (Message), not just the hash of the current transaction. It gets the signature, public key and message from the data stack to check if the signature matches.
Formal proposed by Jeremy Rubin and Brandon Black in November 2024.
OP_CSFS is a powerful tool for implementing more flexible Covenants because it allows for "introspection" of transaction input, i.e. checking the full content or status of a signed transaction.
Specific application:
· Covenants implementation: OP_CSFS can be used to create complex conditional logic to ensure that funds can only be spent on specific rules. For example, a validator can check whether the transaction input meets a preset template or limit.
· Security Enhancement: Supports Vaults and decentralized protocols to prevent theft or unauthorized spending through signature verification.
· Scalability: Combined with other opcodes (such as OP_CAT), more complex smart contracts can be built.
When it comes to the two sets of proposals of Bitcoin Covenants and BIP-119 (CTV) BIP-348 (CSFS), then OP_CAT is definitely indispensable.
BIP 347: OP_CAT
history:
Early existence: OP_CAT is part of the original Bitcoin scripting language, included by Satoshi Nakamoto when Bitcoin was launched in 2009. It was originally designed to enhance script flexibility and support more complex logic.
Reason for removal (2010):
· OP_CAT was removed (disabled) in 2010 to prevent potential security breaches and resource abuse.
· Specific issue: Without restrictions, OP_CAT can be used by malicious users to generate infinitely long data (via recursive call), resulting in a "denial of service attack" (DoS Attack) because Bitcoin nodes need to process this data, increasing computation and storage overhead.
· At that time, the Bitcoin scripting language was simplified, retaining the most basic functions to ensure the lightweight, security and decentralization of the protocol.
Definition and function:
OP_CAT is an opcode (Opcode) of the Bitcoin scripting language (Script). It is not a direct Covenant implementation, but it is a potential tool for building complex Covenant logic. Compared with the above two opcodes, OP_CAT is more general and suitable for data operations, but it needs to be combined with other opcodes to achieve complex functions.
status quo:
The Bitcoin community has re-discussed the return of OP_CAT in recent years. It has previously appeared in the form of a BIP-420 proposal with a more community-based sex symbol, but it is currently officially merged into the bitcoin/bips warehouse with the BIP-347 number.
How is progressing
According to Coindesk, in the past few weeks, many Western Bitcoin developers have expressed support for CTV and CSFS on Twitter - which is undoubtedly a strong signal that at least within the social media circle, some Bitcoin communities are moving towards accepting these changes.
In addition, developers generally believe that the definition of these two proposals is relatively "narrow". In layman's terms, this means that once activated, the possibility of accidental abuse by users is lower. The Bitcoin developer community has always been cautious about the changes in Bitcoin. For example, although BIP 119 has been on hold for nearly five years, not long ago, CTV was seen as too radical and not suitable for activation.
Jeremy Rubin, co-sponsor of the two proposals, had earlier campaigns to promote CTV, faced strong opposition — especially from criticism from Bitcoin opinion leaders with large followings, such as Adam Back and Jimmy Song. All kinds of criticism eventually evolved into widespread dissatisfaction in the Bitcoin community, forcing Rubin to eventually fade out of the Bitcoin space.
So, what exactly contributed to this change? Recent advocacy for OP_CAT opcodes seems to broaden the scope of Bitcoin proposals considered "acceptable" and frame CTV and CSFS as relatively "conservative" options. It is worth noting that most people who support OP_CAT also support BIP 119 and BIP 348 (and most other proposals).
What can we expect next? First, the discussion will continue. Developers are expected to further explore these proposals at several technical meetings, such as OPNEXT scheduled for April, BTC++ in July and TABConf in October. Once the developer has reached a preliminary consensus, the actual activation of the soft fork will be handed over to miners, communities and investors for final confirmation.
**How to follow up on the progress of BIPs’ discussions in the
community/soft hair process?**
The answer is very difficult!
Bitcoin’s tech community often discusses these proposals in depth. But this is a seemingly obscure and cyclical discussion process.
Simply put, the process of Bitcoin's soft fork requires roughly estimating the support of various stakeholders in Bitcoin, including developers, custodians, investors, and miners. The most intuitive support metrics usually come from miners because they can signal recognition of codebase changes by sending signals in the mined blocks. Typically, Bitcoin Core requires that 95% of blocks send a support signal for a period of time before the update is locked to be activated.
However, there is no conclusion on how "broad support" should be defined, and the Bitcoin consensus is always evolving. Miners are important signal providers simply because they are a "countable" entity in the Bitcoin network. In other words, due to the decentralized structure of Bitcoin, it is difficult to measure overall consensus from the perspective of "visible to the naked eye".
However, Taproot Wizards, a development company famous for Bitcoin NFT, uses OP_CAT as an example to reveal the long and complex process of Bitcoin soft forks in the form of flow charts. Interested readers can check it out by https://www.quantumcats.xyz/bip-land. Here we try to summarize:
BIPs Proposal Lifecycle | The Long and Complex Process of Bitcoin Soft Fork
1. The proposal was initially presented and discussed in the mailing list of Bitcoin developers.
2. Enter a larger community-wide discussion and enter a long-term discussion dilemma of the pros and cons of the proposal function. If it cannot be further promoted, it will stop there.
3. Grassroots communities write BIP drafts for proposals on Github.
4. Developers start to implement relevant codes, so they must not continue to move forward without long-term audit bugs.
5. After review by the BIP editor of the Bitcoin warehouse and preliminary recognition by the community, the official BIP number will be assigned.
6. Enter 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. (Maybe most new features will be permanently put on this step)
7. It is possible to enter the Liquid side chain for testing.
8. Submit a PR to Bitcoin Core.
9. Enter the Bitcoin core code review and proposal merge process, highly uncertain. Only when most of the objections are avoided and technical requirements are met (no serious bugs) can the proposal have the opportunity to enter the merge stage; the opinions of key developers (such as Pieter Wuille) are often crucial, and being recognized or rejected can greatly affect the fate of the proposal.
10. If the code review is fine, wait for the Bitcoin warehouse maintainer 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).
11. Continue to be potential disputes and discussions among different groups such as Bitcoin developers and miners.
12. Select the activation mechanism:
a. Miner-dominated soft fork (MASF): New rules are activated by miners via signals (usually 95% threshold), such as the default mode of BIP-9 or BIP-8. It is relatively stable, but requires coordination of extensive consensus and testing, so it takes a long time;
b. User-led soft fork (UASF): New rules (such as "Lockinontimeout: True" of BIP-8) are forced to be activated by node operators (users) to bypass miner resistance, and potential chain fork risks and community disagreements.
Conclusion
Wu said that Bitcoin.org domain name maintainer Cobra warned that the Bitcoin network may usher in a user-led soft fork (UASF) initiated by anonymous developers outside the Bitcoin core in 2025, which is actually the potential changes to BIP 119 mentioned in this article. Cobra believes that these improvements may trigger differences between the "solidification factions" and the "improvement factions", led by grassroots communities and promoted by non-bitcoin core developers.
It is understood that UASF (user-led soft fork) is a protocol upgrade method initiated by Bitcoin users. It enforces protocol updates through the upgrade node software, even if miners or other parties do not support it, it also means the risk of chain fork. Of course, there is no need to worry too much at the moment, after all, many are still unresolved. For example, will future soft forks only include CTV and CSFS? Will the OP_CAT, which is often discussed with this set of opcodes, be included in the consideration? How will the actual activation process of the soft fork be unfolded? Will other stakeholders (such as Bitcoin miners) take it seriously enough?
After all, as long as the consensus on BIPs is large enough, proposals promoted by grassroots communities can also be carried out in the form of miner-led soft forks (MASFs). And even UASF has had success stories in history. UASF played a key role in the SegWit upgrade in 2017, with users successfully promoting soft forks, avoiding hard forks, and promoting Bitcoin expansion.
Reference link:
