Original translation: GaryMa Wu talks about blockchain
According to Blockspace, the Bitcoin grassroots community is beginning to push for changes to Bitcoins underlying software, which is a rare occurrence in more than four years (previously, any major underlying changes were driven by the core developer group).
This time, two Bitcoin Improvement Proposals (BIPs) are gaining grassroots support, 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 function of covenants. These two proposals may be implemented in the next soft fork of Bitcoin.
In order to prevent some readers from temporarily being unable to understand the relationship between Bitcoin Covenants and these specific BIP solutions, we will clarify them here:
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 Covenants?
definition:
Covenants are a proposed mechanism in the Bitcoin protocol that allows conditions or restrictions to be set in transactions, dictating how Bitcoin can be spent or transferred. These conditions can span multiple transactions, restricting future spending methods, thereby enhancing Bitcoins scripting capabilities.
effect:
Improve Bitcoin’s smart contract capabilities to support more complex applications (such as loans, decentralized exchanges, and vaults).
Enhanced security to prevent theft or misuse of funds.
Optimize network performance, such as reducing transaction fees or improving privacy.
Here we can roughly understand that Covenants is a concept, and BIP-119 (CTV) and BIP-348 (CSFS) mentioned in this article are the specific implementations 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 advancing for many years.
BIP 119: OP_CHECKTEMPLATEVERIFY (CTV)
A proposed Bitcoin opcode that allows transaction outputs to specify a template that subsequent spending transactions must match.
Proposed by former Bitcoin Core contributor Jeremy Rubin and now over five years old, it enables “state portability” by limiting funds to be spendable in predefined ways.
Application scenarios include:
Create batch payments to reduce transaction fees. Build decentralized exchanges (DEX) or loan protocols.
Implement Vaults to protect funds from theft.
· CTV is a lightweight implementation of Covenants that focuses on output format restrictions without involving complex logic.
BIP 348: OP_CHECKSIGFROMSTACK (CSFS)
A proposed Bitcoin opcode that allows verifying that a signature is valid for any message, not just the hash of the current transaction. It takes 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 because it allows introspection of transaction inputs, that is, inspecting the complete content or state of a signed transaction.
Specific applications:
Covenants implementation: OP_CSFS can be used to create complex conditional logic to ensure that funds can only be spent according to specific rules. For example, validators can check whether transaction inputs meet preset templates or restrictions.
Security enhancements: Support for Vaults and decentralized protocols to prevent theft or unauthorized spending through signature verification.
Extensibility: Combined with other opcodes (such as OP_CAT), more complex smart contracts can be constructed.
When mentioning Bitcoins Covenants and BIP-119 (CTV) BIP-348 (CSFS) proposals, OP_CAT is definitely indispensable.
BIP 347: OP_CAT
history:
Early existence: OP_CAT is part of Bitcoins original scripting language, included by Satoshi Nakamoto when Bitcoin was launched in 2009. It was originally designed to enhance the flexibility of scripts and support more complex logic.
Reason for removal (2010):
OP_CAT was removed (disabled) in 2010 to prevent potential security vulnerabilities and resource abuse.
· Specific problem: If not restricted, OP_CAT can be used by malicious users to generate infinite length data (through recursive calls), causing a Denial of Service Attack (DoS Attack) because Bitcoin nodes need to process this data, increasing computing and storage overhead.
The Bitcoin scripting language was simplified at the time, retaining the most basic functions to ensure the lightweight, secure, and decentralized nature of the protocol.
Definition and function:
OP_CAT is an opcode of the Bitcoin Script 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:
In recent years, the Bitcoin community has re-discussed the return of OP_CAT. It previously appeared in the form of the more community-friendly BIP-420 proposal, but it has now been officially merged into the bitcoin/bips repository with the BIP-347 number.
How is it going?
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 in the social media circle, part of the Bitcoin community is moving towards accepting these changes.
In addition, developers generally believe that the two proposals are narrowly defined. In laymans terms, this means that once activated, there is a low chance of accidental abuse by users. The Bitcoin developer community has historically been cautious about changes to Bitcoin. For example, even though BIP 119 has been shelved for nearly five years, it was not long ago that CTV was considered too radical to be activated.
Jeremy Rubin, co-sponsor of both proposals, had faced strong opposition to his earlier campaign to promote CTV — especially from some Bitcoin influencers with large followings, such as Adam Back and Jimmy Song. The criticism eventually evolved into widespread dissatisfaction in the Bitcoin community, forcing Rubin to eventually fade out of the Bitcoin field.
So what exactly prompted this change? The recent advocacy for the OP_CAT opcode seems to have broadened the range of Bitcoin proposals that are considered acceptable, framing 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 (as well as most other proposals).
What can we expect next? First, the discussion will continue. Developers are expected to further explore these proposals at several technical conferences, such as OPNEXT scheduled 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 up on the progress of BIPs discussion in the community/soft fork process?
The answer is very difficult!
Bitcoin’s technical community usually discusses these proposals in depth, but it’s a seemingly arcane and circular process.
In simple terms, the process of Bitcoin soft forks requires a rough estimate of the support of various Bitcoin stakeholders, including developers, custodians, investors, and miners. The most intuitive support indicator usually comes from miners, because they can indicate their approval of code base changes by sending signals in the blocks they mine. Usually, Bitcoin Core requires 95% of the blocks to send support signals within a period of time before the update will be locked for activation.
However, there is no consensus on how to define broad support, and 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 Bitcoins decentralized structure, it is difficult to measure the overall consensus from a visible perspective.
However, Taproot Wizards, a development company famous for Bitcoin NFT, uses OP_CAT as an example to reveal the long and complicated process of Bitcoin soft fork in the form of a flow chart. Interested readers can check it out for themselves at https://www.quantumcats.xyz/bip-land. Here we try to summarize it:
BIPs Proposal Lifecycle | The Long and Complicated Process of Bitcoin Soft Forks
1. The proposal was initially proposed and discussed on the Bitcoin developers mailing list.
2. Entering into a larger community-wide discussion, entering into a long-term discussion dilemma on the pros and cons of the proposed function. If no further progress can be made, it will stop here.
3. The grassroots community writes a BIP draft for the proposal on Github.
4. Developers start to implement relevant codes and can move forward only if there are no long-term audit bugs.
5. After review by the Bitcoin Repository BIP editor and initial approval by the community, an official BIP number is 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 are permanently shelved at this step)
7. Possible entry into the Liquid sidechain for experimentation.
8. Submit a PR to Bitcoin Core.
9. Entering the Bitcoin Core code review and proposal merging process is highly uncertain. Only when most objections are avoided and technical requirements are met (no serious bugs) can the proposal enter the merging stage; the opinions of key developers (such as Pieter Wuille) are often crucial, and approval or rejection will greatly affect the fate of the proposal.
10. If the code review is OK, wait for the Bitcoin repository maintainer to merge the PR into the main project. There are currently five maintainers: Michael Ford (fanquake), Hennadii Stepanov (hebasto), Andrew Chow (achow 101), Gloria Zhao (glozow), Ryan Ofsky (ryanofsky).
11. There continues to be potential controversy and discussion between different groups such as Bitcoin developers and miners.
12. Select the activation mechanism:
a. Miner-led Soft Fork (MASF): miners activate new rules through signals (usually 95% threshold), such as the default mode of BIP-9 or BIP-8. It is relatively stable, but requires coordination of broad consensus and testing, so it takes a long time;
b. User-initiated soft fork (UASF): Node operators (users) force activation of new rules (such as BIP-8s Lockinontimeout: True) to bypass miner resistance, with potential chain fork risks and community disagreements.
Conclusion
Wu said that it was previously reported that Cobra, the maintainer of the Bitcoin.org domain, 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 cause a split between the hardening faction and the improvement faction, led by the grassroots community and promoted by non-Bitcoin core developers.
It is understood that UASF (User-Actuated Soft Fork) is a protocol upgrade method initiated by Bitcoin users, which enforces protocol updates by upgrading node software, even if miners or other parties do not support it, which also means the risk of chain forks. Of course, there is no need to worry about it at the moment, after all, many things are still unresolved. For example, will future soft forks only include CTV and CSFS? Will OP_CAT, which is often discussed with this set of opcodes, be taken into consideration? How will the actual activation process of the soft fork unfold? Will other stakeholders (such as Bitcoin miners) pay enough attention to it?
After all, as long as the consensus of BIPs is large enough, proposals promoted by the grassroots community can also be carried out in the form of miner-led soft forks (MASF). And even UASF has successful cases in history. UASF played a key role in the SegWit upgrade in 2017. Users successfully promoted soft forks, avoided hard forks, and promoted Bitcoin expansion.
Reference Links:
