Author: Gabe Parker, Galaxy analyst; Translation: Jinse Finance xiaozou
Bitcoin takes a conservative approach to protocol upgrades, making consensus changes rare. But as shown by previous SegWit and Taproot upgrades, developers are still willing to optimize Bitcoin's programming language and network parameters.
Bitcoin's programming language, Bitcoin Script, cannot enable transactions to carry global state and has introspection capabilities, which limits its expressive power.
There are currently two major proposals, OP_CAT (BIP 347) and OP_CTV (BIP 119), which aim to enhance the programmability of Bitcoin transactions and enable more spending conditions for transaction outputs. These proposals may greatly enhance the functionality of Bitcoin Script and make it more flexible.
OP_CAT and OP_CTV's most promising application scenarios include: Building a trustless cross-chain bridge between Bitcoin's first layer (L1) and second layer (L2)Improvements to advanced self-custodial vault solutions andLightning Network improvements.
The governance process for soft fork upgrades involves multiple Bitcoin stakeholders. In the early stages of protocol conception and technical review, media influencers and core developers have the greatest influence.
Galaxy Research predicts that Bitcoin core developers will reach consensus on OP_CAT or OP_CTV in 2025, but due to the complexity of the activation process, actual implementation may take 1-2 years.
Changes to the Bitcoin protocol require discussion and collaboration among multiple stakeholders, including but not limited to protocol developers, full nodes, end users, and miners. The consensus process for achieving protocol upgrades is complex and controversial. For example, the block size dispute from 2015 to 2017 split the Bitcoin community, with one side wanting to adjust the block size and the other opposing it. Years of debate ultimately led to a permanent fork of the blockchain and the birth of a new cryptocurrency - Bitcoin Cash, a forked version of Bitcoin.
Major upgrades to Bitcoin are rare given the difficulty of reaching consensus on protocol changes. Bitcoin protocol developers have a long history of rejecting controversial upgrades and taking years to implement those that have support from the broader Bitcoin community. This highlights the developer's commitment to a conservative approach to Bitcoin development to promote predictability, network fidelity, and backward compatibility.
Despite the rarity of Bitcoin consensus changes, Bitcoin developers have shown an openness to optimizing Bitcoin scripts and network parameters. The Segregated Witness (SegWit) upgrade, born out of the block size debate, actually increased the block size limit, allowing more transactions to be included in a block. SegWit also optimizes the format of transaction data by changing the unit of measurement of transaction data from bytes to virtual bytes (vbytes). This shift, combined with moving signature data to the witness field, allows a Bitcoin block to contain up to 4m weight units of transaction data (about 4MB). The last soft fork of Bitcoin was the Taproot upgrade in 2021, which introduced an updated scripting language called Tapscript. This new version of Bitcoin Script includes a new signature scheme (Schnorr signatures) and improved key aggregation, combining multiple public keys and signatures into a single signing key. Key aggregation for Schnorr signatures reduces the amount of transaction data that requires multiple signatures while improving the privacy of transactions on the Lightning Network (Bitcoin's largest P2P payment layer, built on top of Bitcoin's base layer). A brief overview of SegWit and Taproot shows that although Bitcoin developers are cautious about consensus changes in Bitcoin, this does not mean that Bitcoin's technical features will not change.
After SegWit and Taproot, Bitcoin developers are now exploring improving Bitcoin's transaction programmability to add additional smart contract logic to transactions. Bitcoin smart contracts involve the use of spending conditions, which is the ability to limit and control how unspent transaction outputs (UTXO) can be spent in the future. More complex and strict spending constraints are called "covenants" ("restriction clauses" or "covenants"). This article will first review Bitcoin Script and how it works with Bitcoin's UTXO accounting model. Subsequently, we will analyze two pending opcodes, OP_CTV and OP_CAT, to highlight how these opcodes have the potential to improve Bitcoin Script to include powerful features that enable efficient transaction programmability. Finally, this article highlights the importance of transaction programmability to Bitcoin infrastructure such as bridges and escrows, and looks forward to the possibility of consensus on OP_CAT and OP_CTV, as well as the path for implementing these opcodes into the next soft fork upgrade.
Bitcoin uses a native scripting language to construct transactions, called "Bitcoin Script". The script consists of a set of instructions that define how the recipient of the transaction can spend the Bitcoin being sent, also known as "spending conditions". Bitcoin Script consists of 186 opcodes that run as command functions. These opcodes are used to create official rules about how Bitcoin assets can be spent and transferred on the network. For example, a Pay-to-PubKey Hash transaction contains 4 opcodes that enforce spending conditions on Bitcoin transactions, where Bitcoins are spent to a hashed public key and can only be spent using the correct public and private keys associated with the spender.
Bitcoin scripts are designed for Bitcoin's Unspent Transaction Outputs (UTXO model), which uses inputs and outputs. Every Bitcoin transaction includes at least 1 input and 1 output, although most simple transactions include at least 1 input and 2 outputs (a portion of the BTC on the input side is used to fund the transaction, a portion is sent to the recipient, and the remainder is returned to the spender on the output side). UTXOs are portions of Bitcoin that have not yet been spent and can be sent in future transactions. Once UTXOs are used as inputs to a transaction, they are no longer outputs. Therefore, UTXOs are constantly being created and destroyed as users spend Bitcoin. Here is an example of a simplified UTXO model:
*If Alice has a UTXO worth 1 BTC in her wallet, and she sends 0.5 BTC to Bob, Alice's input will be 1 BTC. *Her outputs will be 0.49 BTC (returned to Alice) and 0.5 BTC (sent to Bob). The difference of 0.01 BTC represents the BTC paid for the transaction fee (this transaction fee will vary based on network congestion). *At the end of this transaction, Alice will have a new UTXO set representing her remaining 0.49 BTC. In step 1, Alice used her 1 BTC UTXO as the first input of the transaction, destroying the UTXO. In step 2, Alice created two new UTXOs worth 0.5 BTC and 0.49 BTC, one returned to her as her change and the other paid to Bob. In step 3, Alice now has a new UTXO worth 0.49 BTC. Note that if Alice needs to pay Bob 0.5 BTC, Alice can also use multiple UTXOs in step 1, totaling 0.5 BTC; if none of the input UTXOs are fully spent to the recipient, Alice may now receive 2 new UTXOs instead of 1. The UTXO model is a key feature of the Bitcoin network and plays a vital role in transaction processing and verification. The UTXO example above is built entirely using Bitcoin scripts. Each UTXO contains a locking script that includes a set of conditions for the UTXO to be spent. When a user proves ownership of the input (the UTXO being spent) by providing the correct private key signature associated with the corresponding public key, the UTXO's locking script is unlocked. This information is called a "script signature", and when the correct script signature is included in the input, the spending conditions are met and the Bitcoin can be spent. Going back to Alice and Bob's UTXO example, in step 1, Alice must provide her private key signature in her input to spend her UTXO. Subsequently, Bob must provide the same information before spending his newly received 0.5 BTC.
Bitcoin’s scripting language can include more complex spending conditions, such as requiring multiple signatures or unlocking Bitcoin at a specific block height. However, Bitcoin Script is not general-purpose and lacks the expressive power of Ethereum’s native programming language Solidity. Therefore, it is extremely challenging to program smart contract logic for bridge and custody solutions using Bitcoin Script.
Although Bitcoin Script has proven its usefulness to users and its resistance to double-spending attacks over the past 16 years, the scripting language lacks general-purpose features such as expressiveness and the ability to store global state. Bitcoin Script is not expressive because it is a stack-based programming language that cannot perform multiplication and arithmetic operations on large numbers. Bitcoin Script can only perform non-trivial calculations on values of 32 bits in size. As a result, Bitcoin Script isolates stack elements larger than 32 bits from each other. This 32-bit limitation isolates computationally intensive commands using cryptographic functions, multiplication, and division, which require larger script sizes than the current opcode set. While arithmetic and multiplication can be emulated using multiple opcodes, this requires many stack elements, and Bitcoin Script has a stack size limit of 1,000 elements. As a result, it is challenging to create complex spending conditions on transaction outputs that exceed current operations.
The biggest limitation of Bitcoin Script is that the language cannot read/write and store transaction data, as it can only read the inputs provided by the spender. If the programming language cannot store global state, scripts cannot independently verify account balances on applications or bridges. Bitcoin script logic cannot access the global state, as any state data must fit into a single transaction. As a result, it is nearly impossible to develop general-purpose functions or build a trustless bridge between L2 networks and the Bitcoin base layer.
Initiatives to overcome the limitations of Bitcoin Script have been underway since 2020. Over the years, there seems to be a consensus among developers that the only way to improve the expressiveness of Bitcoin scripts is to perform a soft fork upgrade, implementing new opcodes to implement covenants. While one part of the Bitcoin community believes that these upgrades pose a risk to the Bitcoin network, another part believes that Bitcoin needs more programmability features to expand Bitcoin's use cases. Although no substantial progress has been made on which opcode is best suited to improve Bitcoin transaction programmability, advocates of covenants now mostly agree that OP_CTV and OP_CAT are the main Bitcoin Improvement Proposals (BIPs) for enhancing Bitcoin transaction programmability. We understand that there are more than two solutions to implement covenants on Bitcoin, but this article only describes the two most prominent proposals, OP_CTV and OP_CAT.
Bitcoin Improvement Proposal 119 (BIP 119), also known as CHECK-TEMPLATE-VERIFY (CTV), is a proposal proposed by Bitcoin Core developer Jeremy Rubin in January 2020. The proposal introduces a new opcode, OP_CTV, which enables the enforcement of general spending conditions, or covenants, on the outputs of Bitcoin transactions. Here's a brief background. The template part in "CHECK_TEMPLATE_VERIFY" refers to the transaction format that must be followed when writing Bitcoin Script. CHECK-TEMPLATE-VERIFY is a new feature that enables the locking script of a transaction output to commit to spending conditions stored in the locking script as a hash, also known as the commitment hash. Therefore, the transaction output can only be unlocked if the conditions detailed in the commitment hash are met. Once broadcast on the chain, the commitment hash associated with the transaction is immutable. The benefit of OP_CTV is that the sender of the transaction can impose spending conditions on the receiver, which is a major change to the current rules of Bitcoin Script, which can only construct spending conditions for the sender.
There are two main types of Covenants. General Covenants can be copied and applied to multiple UTXOs. Covenants do not expire after the UTXO is spent. On the other hand, precomputed covenants can also be copied, but can only be used a limited, predefined number of times. The logic of a precomputed contract must be specified in advance by the sender, and differs from a general contract in that spending conditions cannot be replicated indefinitely. General contracts, also known as recursive contracts, can pose a risk to the fungibility of UTXO, which is why advocates of BIP 119 generally focus only on OP_CTV use cases that use precomputed contracts, and why BIP 119 does not support general contracts. For example, if general contracts are enabled, a custodian or Bitcoin exchange may be able to process withdrawals with permanent spending conditions, and these Bitcoins may never escape the possibility of being censored by the government or other authorities.
Taking the treasury scheme as an example, here is how the OP_CTV function implements covenants:
Alice wants to spend 0.8 BTC of her 1 BTC UTXO to Bob and Charlie (0.4 BTC each) over the next 10 years. Alice also wants to send her change of approximately 0.2 BTC to a new vault that will lock the BTC for another 10 years.
Step 1:Alice spends her UTXO worth 1 BTC to Bob and Charlie, and details in the locking script that Bob and Charlie can spend the BTC after 525k blocks, which is about 10 years later. Alice also includes instructions detailing that her change output of approximately 0.2 BTC will be sent to a vault address she owns, which will lock her UTXO for 525k blocks, which is about 10 years later.
Step 2:Bob and Charlie spend their respective UTXOs worth 0.4 BTC after 525k blocks. The locking script set by Alice will check the commitment hash against the current block height, and if the conditions are met, Bob and Charlie can spend their new UTXO.
In step 2, after Bob and Charlie spend their UTXO, a portion of the Bitcoin script, also known as the "locking script," will check the fulfillment of the spending conditions, ensuring that all conditions are met before releasing the BTC. This operation is often referred to as "unlocking" the Bitcoin output with the correct script signature. If the conditions are not met, the locking script will not initiate the transfer of BTC.
Step 3: After Charlie and Bob satisfy the commitment hash in the locking script, the UTXO (about 0.2 BTC) returned to Alice as change is used as input to an address with the specified vault script public key. The vault script public key includes a hash that allows Alice to unlock the vault after 525k blocks to spend her UTXO worth about 0.2 BTC. The benefit of using a vault scheme is that Alice can add detailed security measures to the hash, such as a secret recovery address, in case someone steals her private key and tries to unlock the UTXO before the 525k block time lock.
Without covenants, in the previous example, Alice would need to create a pre-signed transaction to enforce future spending conditions on the BTC she spends to Bob and Charlie. A pre-signed transaction can be a single or multiple transactions that are signed in advance by the sender’s private key but are not actually broadcast to the network for confirmation and execution. Pre-signed transactions are not scalable because they require users to store data for multiple transactions until they are executed on-chain. Additionally, pre-signed transactions require interactivity between all signing parties before the funds can be spent. However, implementing covenants using commitment hashes through OP_CTV alleviates the need for users to store pre-signed transaction data and rely on interactivity between all parties associated with the transaction.
Broadly speaking, this feature can be used to create a range of complex, highly secure and resilient custody and security designs that can help improve self-custody or custody setups, create innovative new quorum or business account setups, or create more autonomous execution schemes with greater transparency and reliability.
BIP 347 is another Bitcoin improvement proposal, written by Ethan Heilman and Armin Sabouri in October 2023, which can also implement pre-computed spending conditions on the output of Bitcoin transactions. The proposal proposes to add the OP_CAT opcode to Bitcoin's scripting language, a feature that allows Bitcoin developers to "connect" two data points together in the stack and put those values on the top of the stack. Let's take a look at a brief background introduction. "Concatenating" is the process of combining two or more code strings into a larger string of bytes or data. Bitcoin Script is a stack-based programming language that evaluates each code string in sequence. For a stack consisting of 5 lines of code, Bitcoin Script will calculate line 1 first and line 5 last. Unfortunately, Bitcoin's scripting language does not contain opcodes that allow developers to merge multiple code strings throughout the stack. Currently, Bitcoin Script lacks arithmetic and multiplication functions, inhibiting the ability to compress Bitcoin Script, which limits the interaction of large scripts (greater than 32 bits) and small scripts (less than 32 bits) in a single stack. Complex spending conditions on transaction outputs are not feasible without the ability to compress scripts and allow large scripts to communicate with small scripts through "concatenation." Crucially, the concatenated elements of Bitcoin Script at the top of the stack can emulate arithmetic and multiplication functions, enabling complex scripts without the need to write long, data-intensive scripts that are more prone to errors. Additionally, the concatenation feature of OP_CAT allows developers to generate spending conditions using Merkle trees and other hash data structures in Tapscript, the native scripting language used to enable new transaction types as part of the Taproot upgrade activated in November 2021. Notably, Satoshi disabled OP_CAT, as well as other opcodes that enable Bitcoin Script to perform complex mathematical operations directly within the script. Satoshi Nakamoto himself deleted OP_CAT because the opcode combined with OP_DUP could build data-intensive scripts when Bitcoin scripts were limited to 2000 bytes at the time. Scripts of this size could burden and overload the computing resources of Bitcoin nodes. However, the Taproot upgrade introduced a size limit (520 bytes) for Taproot scripts in 2021, so OP_CAT no longer introduces too much computational overhead for node operators.
The 2021 Taproot upgrade introduces Schnorr signatures to the Bitcoin script language. Schnorr signatures support public and private key aggregation, allowing multiple parties to jointly sign a transaction with a single signature. Combining the verification opcodes contained in Schnorr signatures with OP_CAT creates a non-recursive contract that generates a transaction hash. OP_CAT allows users to constrain certain parts of a transaction, such as the sending address or the sending amount, as requirements for the unlocking script, and the transaction hash as the key to unlocking.
Using the vault scenario as an example, the following is a general overview of how OP_CAT functions to implement Covenants. The technical details of this example are beyond the scope of this article.
Alice wants to create a vault that unlocks her UTXO after 100 blocks:
*Step 1: Alice spends her UTXO to a vault address and includes the details of the spending conditions of the vault unlocking script in the witness field, including the block height.
*Step 2: In Alice's transaction, OP_CAT concatenates the vault unlocking instructions in the witness field and hashes them twice to get the sighash/txhash.
*Step 3:After 100 block confirmations, Alice initiates the process of spending her vault bitcoins by broadcasting a spend transaction for the vault UTXO. To verify that Alice has met all of the spending conditions, her wallet executes the CheckSig opcode in the background. This operation performs two key verifications: it verifies the transaction hash from the initial setup transaction (step 1) and compares it to the current spending transaction (step 3). The CheckSig function reconstructs the components of the setup transaction and verifies the public key signature of the current transaction to ensure that all vault spending conditions have been met.
*Step 4:After the public key of Alice's transaction is verified by CheckSig (CheckSig reconstructs the spending conditions stored in the witness field), Alice is free to spend her UTXO.
The above examples demonstrate that OP_CAT by itself cannot enforce spending conditions on transactions, but rather that OP_CAT combined with other opcodes in Bitcoin Script can simplify scripting to implement covenants. The only functionality of OP_CAT is to concatenate the top two elements of the stack.
While OP_CAT can be used with CheckSig to create covenants, simply adding OP_CAT does not bring Solidity-like functionality to Bitcoin Script. This limitation also applies to simply adding OP_CTV. Even with OP_CAT, Bitcoin transactions can only perform minimal introspection, meaning that transactions do not have full access to elements or state of previous transactions. Therefore, OP_CAT can only support fine-grained covenants for Taproot transaction outputs. OP_CAT cannot fix the leaf nodes of a Taproot output or verify the internal keys used. Taproot leaf nodes are individual spending conditions or scripts submitted to a Taproot output. They can be thought of as different "paths" or ways to spend Bitcoin - each leaf node represents a possible way to spend it. The internal key in the Bitcoin Taproot transaction is the main public key used for the most efficient spending path. When spending a UTXO using the internal key, you only need to provide a signature on the chain without revealing any scripts or Merkle paths.
It is important to note that these limitations can be addressed by other opcode proposals such as OP_TWEAK_VERIFY and OP_INTERNALKEY. Overall, OP_CAT can be seen as the main building block for generating complex spending conditions on transaction outputs, however, other building blocks including CheckSig are critical to advancing the development of Bitcoin transaction programmability.
(1) Trustless bridging and unilateral exit
Starkware (creator of Starknet zk-rollup on Ethereum) released a report highlighting how OP_CAT supports the creation of STARK validators and Merkle validators to achieve trustless Bitcoin bridging. Trustless bridging is built through a recursive contract system that maintains the bridge state through a chain of transactions recorded in a Merkle tree. The core of this mechanism is the bridge persistent state stored in an unspendable OP_RETURN output, which contains the root hash of the Merkle tree representing the account balance. OP_CAT covenant requires that each new deposit or withdrawal transaction contains a valid state transition that reflects the current bridge state. Users interact with the bridge through specialized deposit and withdrawal covenants that use Merkle trees to aggregate multiple transactions into batches for efficient verification. The root of this Merkle tree is then merged into the main bridge contract, which verifies and processes each deposit or withdrawal. During a withdrawal, the contract verifies ownership by ensuring that the withdrawal address matches the address of the first input in the leaf transaction. The design leverages Merkle proofs for efficient state updates in Bitcoin Script, creating a trustless system where the state and rules of the bridge are fully enforced through on-chain contract logic created by OP_CAT, without the need for third-party trust. Crucially, for trustless Bitcoin bridges to verify end-system state transitions, Bitcoin scripts require verification proofs. OP_CAT builds the ability of STARK validators into Bitcoin Script by concatenating hash data together, enabling UTXO locking scripts to verify zk-proofs of end-system state transitions.
The Taproot Wizard team has innovated a new trustless bridge framework that combines OP_CAT with BitVM. BitVM achieves Turing-complete expressiveness by allowing arbitrary computations to be split and executed on Bitcoin. BitVM splits the runtime of arbitrary computations that leverage Bitcoin Script into multiple transactions on Bitcoin. Without covenants, the BitVM bridge that locks Bitcoins requires a pre-signed transaction to set up the bridge. OP_CAT’s ability to carry data from previous transactions enables the BitVM bridge to lock and unlock Bitcoins without pre-signed transactions. OP_CAT can carry data from previous transactions through a trick called “CAT on the stack.” The trick involves concatenating hashed data on the stack to build a Merkle tree root that OP_CAT can verify. Thus, the CatVM bridge ensures that specific transaction data from previous transactions, deposits, and withdrawals, must be included in the next transaction to guarantee that the Merkle root is continued after a successful withdrawal. The CAT on the stack trick also ensures that after a user withdraws, the remaining bridged Bitcoins can be withdrawn by any eligible user.
(2) Advanced Vault Custody
Bitcoin Vault is a new custody solution that includes security features such as recovery paths, allowing users to withdraw their Bitcoin to a secret address in the event of a private key compromise. BIP 345, formally known as OP_VAULT, is a pending Bitcoin Improvement Proposal that leverages OP_CTV to enhance the security parameters of Bitcoin custody. It is important to note that OP_CAT can also be used to create spending conditions for Bitcoin Vaults without the need for pre-signed transactions. Bitcoin Core developer James O’Beirne proposed OP_VAULT in January 2023 to narrow the use case for OP_CTV. OP_VAULT relies on OP_CTV to create spending conditions for Vault Bitcoins without the need for depositors to pre-sign multiple transactions. Covenants allow Vaults to have time delays that are triggered when anyone attempts to spend Vault Bitcoins before the original time lock, typically an attacker trying to steal funds.
（3）Non-Equivocation Contract
Non-Equivocation Contract was introduced to the Bitcoin network in 2015. It is a Bitcoin transaction output that leaks the signing key if the signer double-spends it. In practice, users lock up native Bitcoin as a forfeitable security deposit. This security deposit allows users to perform 0-confirmation transactions on the base layer, which are later mined in a block. 0-confirmation transactions are instant Bitcoin transactions verified and protected by Bitcoin consensus rules. If the sender of a 0-confirmation transaction spends the input before the transaction is mined, the counterparty can forfeit its Bitcoin security deposit from the leaked signing key.
（4）Improvements to the Lightning Network
OP_CAT can enable Channel Factories, allowing users to open Lightning channels without first broadcasting a channel opening transaction on the Bitcoin base layer. For example, if Alice wishes to create 2 lightning channels (one with Bob and the other with Charlie), Alice will broadcast a channel opening transaction with Bob and Charlie (2 transactions). The channel opening transaction requires both parties to deposit Bitcoin into a 2/2 multisignature address. With the Channel Factory, Bob and Charlie can open separate channels with each other without broadcasting a new channel opening transaction. Therefore, all participants in the original channel opening transaction can create independent channels with each other. OP_CTV can create shared UTXOs, where one UTXO represents multiple users. Shared UTXOs using CTV can enable multiple users to open multiple lightning channels with one on-chain transaction. Typically, each lightning channel requires one on-chain transaction. Therefore, if many users open lightning channels, this may fill the memory pool with pending transactions and increase transaction fees. While this is not a problem at present, channel opening needs to scale to support the lightning network to attract millions of active users.
All Bitcoin soft forks contain technical risks, such as bugs or unforeseen use cases for new opcodes. While the former is rare, the latter is exposed in the creation of inscriptions. Inscriptions involve entering arbitrary data in the witness field of a transaction, which has been used to create new tokens and NFT collections on Bitcoin. SegWit and Taproot upgrades together enable users to enter images and text data as string data into the witness field. While the creation of digital art and fungible tokens was not the focus of activating SegWit or Taproot, years later, clever developers discovered how to use these upgrades for other purposes. Galaxy Research highlights this point in our Ordinals report, noting that inscriptions accidentally created through SegWit and Taproot could have a negative impact on future Bitcoin upgrades, as the community's surprise at these new use cases could make it more hesitant to support new soft forks.
Despite the bearish sentiment about Bitcoin's ability to upgrade, OP_CAT and OP_CTV have been heavily tested and researched. An initial criticism of covenants was that governments could force applications to enforce spending conditions that only allow a set of approved addresses to spend Bitcoin. This criticism is invalid because the conditions for spending conditions are determined by the user who owns the funds. Users can create transactions that restrict future spending to specific addresses, but these restrictions cannot be enforced externally by third parties and cannot be perpetually extended after locked funds are spent. Therefore, governments cannot enforce how self-custodial vault applications or bridges spend funds. While custodians and Bitcoin exchanges can still restrict how users spend funds, they cannot add permanent spending conditions to withdrawing funds without the ability to enforce general contracts, which OP_CTV does not allow.
Overall, OP_CAT and OP_CTV are simple opcodes that each perform one function very well. OP_CAT concatenates the two elements at the top of the stack, while OP_CTV can hash spending conditions in the locking script. Some use cases for these opcodes, such as the development of trustless bridges, still require further research and field testing, as bridges are extremely vulnerable to bugs and hacker attacks.
Determining Bitcoin stakeholder consensus on future protocol upgrades is a complex process that evolves over the lifecycle of a proposal, also known as the BIP (Bitcoin Improvement Proposal) process. BCAP’s report on Bitcoin’s upgrade history details the roles of these stakeholders as follows:
* Economic nodes: Exchanges, custodians, merchants, payment providers
* Investors: Whales, MicroStrategy, ETF providers, Galaxy
* Media celebrities: CoinDesk, Bitcoin Magazine, X celebrities, podcasters
* Miners: Bitmain, MicroBT, Riot, Marathon, large private miners
* Protocol developers: Bitcoin core developers
* Application developers: L2 projects
Throughout the lifecycle of a Bitcoin Improvement Proposal (BIP), different stakeholders exercise varying degrees of influence, and their relative influence changes during the consensus-building process to implement a soft fork. Below is a breakdown of the influence levels of each stakeholder, ranked 1-10. As of March 2024, OP_CAT and OP_CTV are in the protocol ideation phase. During this phase, media figures have the most influence, as they can sway public opinion and create narratives. For example, Taproot Wizards is a team of well-known Bitcoin influencers who use their large social media followings to educate the Bitcoin community on the benefits of OP_CAT. The Taproot Wizards team has been producing educational content and research about OP_CAT to push the narrative that Bitcoin Script needs new opcodes to enhance transaction programmability. As a result, Taproot Wizards has cultivated a large group of supporters for OP_CAT, who are pushing Core Developers to review the OP_CAT BIP draft.
During the protocol ideation phase, Bitcoin Core Developers rank second in influence, as BIP Editors are responsible for reviewing drafts of pending BIPs and, most importantly, are the only entity that can merge BIPs into the Bitcoin Core GitHub repository. Without the support of Bitcoin Core developers, BIPs will inevitably be shelved and eventually rejected. Bitcoin Core developers are also responsible for maintaining the Bitcoin codebase and ensuring that it does not contain any bugs. Reaching consensus among Bitcoin Core developers is a difficult process because ideological views can differ between core developers, and the influence of each core developer in the decision-making process varies depending on their contributions and background.
OP_CAT and OP_CTV BIPs are at a stage where media influencers, users, and application developers are using their influence to convince Bitcoin Core developers that these consensus changes will improve the programmability of Bitcoin transactions. The next phase of the consensus journey will require specific research by technical luminaries, application developers, and core developers detailing all the potential risks of OP_CAT and OP_CTV. Without specific research and open dialogue with core developers, there will not be a collective opinion on OP_CAT and OP_CTV from the broader core developer community.
Once consensus is reached among core developers, OP_CAT and OP_CTV will need to designate a lead maintainer to facilitate the final steps of implementing the BIP into the Bitcoin Core repository. After the BIPs for OP_CAT and OP_CTV are merged into the Bitcoin Core repository, an activation method must be decided. Once an activation method is chosen, the signaling period begins, with miners, investors, and economic nodes having the most influence. As of March 2024, miners, large investors such as Microstrategy, and economic nodes such as Coinbase have not expressed a public opinion on OP_CAT and OP_CTV. These stakeholders need to further understand the risks and benefits of OP_CAT and OP_CTV before the BIPs are implemented.
If Bitcoin Core developers agree to include OP_CAT or OP_CTV into the next soft fork upgrade, the community needs to agree on the activation method for the BIP. The activation method allows miners to signal their readiness for the upgrade.
Broadly speaking, there are two ways to perform code changes on Bitcoin. First, code changes can be performed through a soft fork. Soft forks are backwards-compatible upgrades that allow Bitcoin node operators to safely operate on the Bitcoin network even without upgrading their client software. Another benefit of soft fork backward compatibility is that anyone who disagrees with the direction of Bitcoin Core (the main Bitcoin client) can choose to run an older version of the client software that excludes the activation of the new BIP, but can still connect to the canonical Bitcoin blockchain. Soft forks add functionality by creating new conditions that are more limited than the existing rule set, so they fit into the existing rules.
When a soft fork is activated by users (rather than miners), it is known as a user-activated soft fork (UASF). The most famous example of a UASF on Bitcoin almost occurred during the "block size war" on August 1, 2017, to help speed up the adoption of the SegWit upgrade. During the block size war, Bitcoin users upgraded their nodes to support the SegWit upgrade and subsequently threatened to reject blocks from non-upgraded nodes. By doing so, miners who had not upgraded their Bitcoin client software were encouraged to adopt Segwit in order to make their blocks more widely propagated and increase their chances of receiving block rewards. While a UASF never occurred during the block size war, the threat of a potential UASF influenced miners to adopt SegWit.
The second way to implement code changes is through a hard fork, which is a backwards-incompatible upgrade that permanently splits consensus between upgraded and non-upgraded nodes. Bitcoin Core developers have never implemented a hard fork because the community values solidification and backward compatibility of the protocol code. Bitcoin could experience a chain split if a minority of users performed a hard fork upgrade, such as a block size change. This is how Bitcoin Cash was created in 2017, when a portion of the Bitcoin community disagreed with the Segwit upgrade and instead wanted to fork from the Bitcoin protocol by activating a backwards-incompatible code change to simply increase the block size.
In addition to the distinction between hard fork and soft fork activations, there are different ways to gauge community sentiment towards an upgrade before a fork occurs. Here is an overview of the various types of process BIPs proposed by the Bitcoin community to better support the activation of soft fork upgrades:
*BIP 9:BIP 9 provides a framework for miners to signal their support for soft fork upgrades by modifying the version bit field in the Bitcoin block header. Once the signaling period is over, the Bitcoin community can assess the percentage of miners who support the upgrade and vote weighted by miner hashrate. If a certain support threshold is exceeded, the upgrade can proceed to activation on a “flag day”, which is simply a designated block height for the upgrade to activate.
*BIP 8:Long-time Bitcoin Core developer Luke Dashjr (who has been working on Bitcoin since 2011) proposed BIP 8 in February 2017 as a successor to BIP 9. BIP 8 proposes using block height rather than hashrate to determine the duration of the signaling period for approving proposals. BIP 8 also introduces a new on-chain activation soft fork parameter called “LOT”. If this parameter is set to “TRUE”, signaling is required during the finalization period, ensuring that the soft fork is locked at the timeout height. From here on, upgrades are activated by nodes on a predefined flag day, regardless of whether miners signal or not. BIP 8 attempts to reduce miner interference in the activation of proposals that the community wants, and forces miners to consider the consequences of lost revenue due to not receiving blocks from upgraded nodes if the LOT parameter of an upgrade is set to TRUE.
*Speedy Trial:A version of BIP 8 called "Speedy Trial" was introduced in April 2021 by Bitcoin Core developers AJ Townes and Andrew Chow. Speedy Trial attempts to speed up the timeline for miners to signal readiness for activation. This approach means that the proposal will be activated once a majority of mined blocks signal readiness within a specified period. Speedy Trial functions similarly to BIP 9 activation deployment, but with a shorter activation window. Recently, the Taproot upgrade was activated on Bitcoin via Speedy Trial. The trial required 90% of mined blocks to signal readiness within two weeks before Taproot could be activated on the network. The trial ended on June 12, 2021. After reaching the threshold of 90% miner support, the network then entered a five-month waiting period to give miners and nodes time to upgrade their software. Taproot was then officially activated on Bitcoin on November 15, 2021.
*Modern Soft Fork Activation:This is an upgrade activation method that combines different attributes of BIP 9 and BIP 8. It was proposed by Matt Corallo, one of Bitcoin Core's most prolific contributors, in January 2020. The method consists of three steps. The first step is a miner-activated soft fork as outlined in BIP 9. If miners fail to activate the upgrade, the modern soft fork activation process outlined by Corallo defaults to the second step, which is a six-month waiting period for developers and the broader Bitcoin community to reconsider the code change. After six months, if developers and users wish to proceed with the upgrade, they can initiate the third step, which is essentially equivalent to BIP 8 with the LOT parameter set to TRUE.
Although OP_CAT (BIP 347) and OP_CTV (BIP 119) have received support from many well-known Bitcoin developers, these proposals still need to go through a long due diligence process before implementation. This is because OP_CAT and OP_CTV require changes to Bitcoin's consensus layer, and the BIP governance process for such changes is very extensive. Although the activation schedule of BIP 119 and BIP 347 is unclear and unpredictable, the long review period may be beneficial to the proposal because it provides the community with ample time to understand the benefits and impacts of OP_CTV and OP_CAT. In addition, BIP contributors will have more time to stress test OP_CTV and OP_CAT, as well as their potential impact on future bugs in Bitcoin scripts.
While the full potential of OP_CAT and OP_CTV is still being explored, their most immediate impact is in enabling trustless bridges for Bitcoin L2 and advanced secure Bitcoin vaults. The importance of trustless bridges for EVM-compatible Bitcoin L2 cannot be overstated, especially in the context of the continued development of Bitcoin DeFi. These trustless solutions represent a significant advancement over current alternatives such as WBTC and cbBTC, which rely on trusted intermediaries and weaken the permissionless nature of blockchain technology. While self-custodial Bitcoin vaults may provide the most practical value among custody solutions, the potential of trustless L2 bridges demonstrates the broader possibilities that enhanced transaction programmability brings to Bitcoin.
The developer community has made significant progress in pushing these proposals in 2024, and this momentum may continue into 2025. With Bitcoin transaction activity trending downward and transaction fees as low as 1 sat/VB, the current focus is turning to how to restore transaction activity on the Bitcoin network. Although our Galaxy Research 2025 forecast report believes that Bitcoin Core developers will reach a consensus between OP_CAT or OP_CTV, the final implementation and activation process may take another 1-2 years. Nevertheless, the final adoption of these proposals will become an important milestone in the evolution of Bitcoin script, laying the foundation for more complex and secure Bitcoin applications in the future.
By enhancing transaction programmability, Bitcoin will be able to support more innovative use cases, such as trustless cross-chain bridging and advanced custody solutions, further promoting the development of the Bitcoin ecosystem. The introduction of these technologies will not only enhance Bitcoin's functionality, but will also provide developers and users with more tools to build safer and more efficient decentralized applications. Although achieving these goals will take time and the joint efforts of the community, their potential impact will undoubtedly inject new vitality into the future of Bitcoin.
According to analysis by Wall Street experts, billionaires are selling Nvidia shares and instead buying index funds that may soar 83,000%.
WeiliangStory Protocol raised $80 million in Series B funding to address IP theft by AI, including models like OpenAI’s ChatGPT, valuing the company at $2.25 billion. The blockchain-based platform ensures creators are compensated for their work when used by AI, aiming to protect IP rights in the digital age.
JoySun Yuchen successfully pushed the "Sun Wukong" virtual currency up 391 times by using marketing methods such as changing avatars and redeeming game codes, and all of this was closely related to the popularity of "Black Myth: Wukong".
Miyuki孙宇晨用头像更换和游戏兑换码的营销手段，成功推动了“孙悟空”虚拟货币暴涨391倍，而这一切都与《黑神话：悟空》大热密切相关。
MiyukiThe U.S. federal government will contact victims of a million-dollar cryptocurrency scam via NFTs after the founder pleaded guilty.
WeiliangRNDcoin.kr, a crypto platform, enhances your understanding of digital currencies through educational resources together with social network Steemit. But with nary a presence and a lackluster website, how can it stand out?
KikyoThis article provides a detailed cryptocurrency withdrawal guide for Chinese investors around the world, introduces how to safely withdraw cryptocurrency from trading platforms to bank cards, and shares multi-currency conversion tips.
AlexWilly Bum Bum, a viral sensation now facing significant challenges, has launched its own memecoin, $BUM, despite recent value declines and skepticism. The coin, created by a doxxed team and backed by a capped supply and strategic token allocation, is struggling with a 23.86% drop in value and low trading volume, reflecting waning investor interest.
AnaisMusk and Vitalik Buterin voiced their support for the Telegram founder, whose arrest at a French airport has caused panic in the cryptocurrency community, with Russia pointing the finger at the United States.
AlexThis article briefly analyzes the various safe ways to withdraw funds after purchasing virtual currency, including withdrawals to bank cards, P2P transactions, and cryptocurrency exchange services, and compares their fees and risks to help investors choose the most suitable withdrawal path.
Miyuki