Original Translation: GaryMa Wu Discusses Blockchain
According to Blockspace, the Bitcoin grassroots community has begun to push for changes to the underlying Bitcoin software, which is a rare occurrence in over four years (previously significant underlying changes were primarily driven by the core developer group).
The grassroots support emerging this time is for two Bitcoin Improvement Proposals (BIPs), namely BIP-119 (CTV) and BIP-348 (CSFS). These two proposals introduce new ways to script Bitcoin, enabling the functionality of "Covenants." These proposals may be implemented in the next Bitcoin soft fork.
To help some readers who may not yet understand the relationship between Bitcoin's Covenants and these specific BIP proposals, let's clarify:
In simple terms, Covenants are a functional concept within the Bitcoin network, while the two BIPs mentioned in the text are different implementation schemes to realize this functional concept.
What are Bitcoin's 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, limiting future spending methods and thereby enhancing Bitcoin's scripting capabilities.
Functions:
- Enhance Bitcoin's smart contract capabilities, supporting more complex applications (such as loans, decentralized exchanges, vaults).
- Improve security, preventing funds from being stolen or misused.
- Optimize network performance, such as reducing transaction fees or increasing privacy.
Here we can clearly see that Covenants are a concept, while the BIP-119 (CTV) and BIP-348 (CSFS) mentioned in this article are specific implementations of the Covenant functional concept.
Current Status:
The Bitcoin mainnet has not yet officially integrated any Covenant-related functionalities, although discussions and proposals (such as BIP-119) have been ongoing for years.
BIP 119: OP_CHECKTEMPLATEVERIFY (CTV)
A proposed Bitcoin opcode that allows transaction outputs to specify a "template," requiring subsequent spending transactions' outputs to match that template.
Proposed by former Bitcoin core contributor Jeremy Rubin, it has existed for over five years. It achieves the functionality of "state carrying" by restricting funds to be spent only in predefined ways.
Use Cases Include:
- Creating batch payments, reducing transaction fees. Building decentralized exchanges (DEX) or loan protocols.
- Implementing Vaults to 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 verification of whether a signature is valid 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 allows introspection of transaction inputs, meaning it can check the complete content or state of the signed transaction.
Specific Applications:
- Covenant Implementation: OP_CSFS can be used to create complex conditional logic, ensuring funds can only be spent according to specific rules. For example, validators can check if transaction inputs meet preset templates or restrictions.
- Security Enhancement: Supports Vaults and decentralized protocols, preventing theft or unauthorized spending through signature verification.
- Scalability: In combination with other opcodes (like OP_CAT), it can build more complex smart contracts.
When discussing Bitcoin's Covenants and the proposals BIP-119 (CTV) and BIP-348 (CSFS), we cannot overlook OP_CAT.
BIP 347: OP_CAT
History:
Early Existence: OP_CAT was part of Bitcoin's original scripting language, included by Satoshi Nakamoto when Bitcoin was launched in 2009. It was initially designed to enhance the flexibility of scripts, supporting more complex logic.
Reason for Removal (2010):
- OP_CAT was removed (disabled) in 2010 to prevent potential security vulnerabilities and resource abuse.
Specific Issues: Without restrictions, OP_CAT could be exploited by malicious users to generate infinitely long data (through 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, Bitcoin's scripting language was simplified to retain only the most basic functionalities, ensuring the protocol's lightweight nature, security, and decentralization.
Definition and Function:
OPCAT is an opcode in Bitcoin's scripting language (Script). It is not a direct implementation of Covenants, but it is a potential tool for building complex Covenant logic. Compared to the aforementioned two opcodes, OPCAT is more general and suitable for data manipulation, but it needs to be combined with other opcodes to achieve complex functionalities.
Current Status:
The Bitcoin community has recently revisited the discussion of OP_CAT's return, previously appearing in a more community-oriented proposal known as BIP-420, but it is now formally merged into the bitcoin/bips repository under the number BIP-347.
How is Progress?
According to Coindesk, in recent weeks, many Western Bitcoin developers have expressed support for CTV and CSFS on Twitter—this is undoubtedly a strong signal indicating that at least within the social media sphere, parts of the Bitcoin community are moving towards accepting these changes.
Additionally, developers generally believe that the definitions of these two proposals are relatively "narrow." In simple terms, this means that once activated, the likelihood of accidental misuse by users is low. The Bitcoin developer community has historically been cautious about changes to Bitcoin. For instance, although BIP 119 has been shelved for nearly five years, CTV was recently considered too radical to activate.
The co-initiator of these two proposals, Jeremy Rubin, faced strong opposition in his earlier efforts to promote CTV—especially from some Bitcoin opinion leaders with large followings, such as Adam Back and Jimmy Song. Various criticisms ultimately evolved into widespread dissatisfaction within the Bitcoin community, forcing Rubin to step back from the Bitcoin space.
So, what has driven this change? Recent advocacy for the OPCAT opcode seems to have broadened the range of Bitcoin proposals considered "acceptable," framing CTV and CSFS as relatively "conservative" options. Notably, most supporters of OPCAT 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/Soft Fork Process?
The answer is quite difficult!
The Bitcoin technical community typically engages in in-depth discussions about these proposals. However, this is a seemingly obscure and cyclical discussion process.
In simple terms, the soft fork process for Bitcoin requires a rough estimate of the support levels among various stakeholders, including developers, custodians, investors, and miners. The most intuitive support indicators usually come from miners, as they can signal their approval of codebase changes by signaling in the blocks they mine. Typically, Bitcoin Core requires 95% of blocks to signal support over a period before locking the update for activation.
However, there is currently no consensus on how to define "broad support," as 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 Bitcoin's decentralized structure, it is challenging to measure overall consensus from a "visually observable" perspective.
However, a development company known for Bitcoin NFTs, Taproot Wizards, has used OP_CAT as an example to reveal the long and complex process of Bitcoin soft forks through flowcharts. Interested readers can check it out at https://www.quantumcats.xyz/bip-land; here we will try to summarize:
BIPs Proposal Lifecycle | The Long and Complex Process of Bitcoin Soft Forks
The proposal is initially raised and discussed in the Bitcoin developers' mailing list.
It enters a broader community discussion, entering a long-term discussion dilemma about the pros and cons of the proposal's functionality. If it cannot be further advanced, it stops there.
The grassroots community writes a BIP draft for the proposal on GitHub.
Developers begin related code implementation, which must pass long-term bug audits to proceed.
After review by Bitcoin repository BIP editors and preliminary community approval, a formal BIP number is assigned.
It 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 mainnet. (Most new features may remain permanently shelved at this step.)
It may enter the Liquid sidechain for experimentation.
A PR is submitted to Bitcoin Core.
It enters the Bitcoin core code review and proposal merging process, which is highly uncertain. A proposal only has a chance to enter the merging stage if it avoids most objections and meets technical requirements (no serious bugs); the opinions of key developers (like Pieter Wuille) are often crucial, and their approval or rejection can significantly impact the proposal's fate.
If the code review is satisfactory, wait for 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).
There will continue to be potential disputes and discussions among different groups, such as Bitcoin developers and miners.
Choose an activation mechanism:
a. Miner-Activated Soft Fork (MASF): New rules are activated by miners through signaling (usually a 95% threshold), as in the default modes of BIP-9 or BIP-8. This is relatively stable but requires coordination of broad consensus and testing, thus taking a longer time;
b. User-Activated Soft Fork (UASF): New rules are forcibly activated by node operators (users) (such as "Lockinontimeout: True" in BIP-8), bypassing miner resistance, with potential risks of chain forks and community divergence.
Conclusion
Wu previously reported that Cobra, the maintainer of the Bitcoin.org domain, warned that in 2025, the Bitcoin network might face a user-activated soft fork (UASF) initiated by anonymous developers outside of Bitcoin Core, referring to the potential changes of BIP 119 mentioned in this article. Cobra believes that these improvements could lead to a divergence between the "conservative faction" and the "improvement faction," driven by the grassroots community and pushed by non-Bitcoin Core developers.
It is understood that UASF (User-Activated Soft Fork) is a method of protocol upgrade initiated by Bitcoin users, enforcing protocol updates by upgrading node software, even if miners or other parties do not support it, which also implies the risk of chain forks. Of course, there is no need to worry excessively at this point, as many issues remain unresolved. For example, will future soft forks only include CTV and CSFS? Will OP_CAT, which is 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) pay enough attention?
After all, as long as the consensus on BIPs is large enough, proposals driven by the grassroots community can also be carried out in the form of a miner-activated soft fork (MASF). Moreover, there have been successful historical cases of UASF. UASF played a key role in the SegWit upgrade in 2017, where users successfully pushed for a soft fork, avoiding a hard fork and facilitating Bitcoin's scalability.
Reference Links:
https://www.quantumcats.xyz/bip-land
https://github.com/bitcoin/bips
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
