Bitcoin Scaling: The Journey of OP_CAT and OP_CTV

Summary

Bitcoin is famous for its cautious approach to protocol upgrades, making consensus changes rare. However, developers are constantly optimizing the programming language and network parameters, as seen with SegWit and Taproot. Bitcoin Script, a simple language used to verify and execute transactions, is currently limited in its expressiveness due to its lack of global state and flexibility in setting conditions.

Two upcoming major upgrade proposals, OP_CAT (BIP 347) and OP_CTV (BIP 119), aim to expand programmability by adding spending conditions to outputs, making scripting more flexible. Potential applications include trustless bridges between Layer 1 and Layer 2, advanced self-custody vaults, and Lightning Network improvements. Soft fork implementation requires community consensus, with developers and KOLs playing a key role in the early stages. HCC Ventures predicts that Bitcoin Core could reach consensus on OP_CAT or OP_CTV by 2025, but activation could take another 1-2 years due to complexity.

Bitcoin was created after the 2008 financial crisis by Satoshi Nakamoto, with the goal of creating a decentralized monetary system, independent of governments or banks. Nearly 20 years later, Bitcoin has affirmed its value and position in the financial industry, but compared to Ethereum, it has only undergone two major upgrades: SegWit (2017) increased block capacity and reduced fees by separating digital signatures, and Taproot (2021) improved privacy, reduced fees and supported smart contracts. Despite being the most valuable digital asset, Bitcoin is still limited in terms of programmability, fee management, network congestion, Lightning Network scaling and lack of trustless bridges to Layer 2.

Since 2020, the community has been working on upgrading Bitcoin Script through a soft fork, adding new opcodes to increase expressiveness. Two opposing opinions have emerged: one side is concerned about risks, the other side believes that Bitcoin needs to expand its features. OP_CAT and OP_CTV, if adopted, could improve scalability, optimize costs, increase security, and support complex financial applications, although the implementation process will take a long time due to Bitcoin's conservative nature.

Overview of Bitcoin and Previous Upgrades

Bitcoin operates on a cautious approach to protocol upgrades, resulting in consensus changes being rare. In its nearly 20 years of existence (as of 2025), Bitcoin has only undergone two major upgrades:

• SegWit (2017): Separates digital signatures (witness) from transaction data, increasing block capacity, reducing transaction fees, and improving network performance.

• Taproot (2021): Enhances privacy, reduces transaction fees, and supports smart contracts by obfuscating complex spending conditions, while introducing Schnorr Signatures to optimize group signatures.

However, compared to Ethereum – a blockchain with more flexible programming capabilities – Bitcoin is still limited by Bitcoin Script and the UTXO model, making it difficult to extend functions such as the Lightning Network or trustless bridges to Layer 2. OP_CAT and OP_CTV are expected to overcome these limitations.

Bitcoin Script and Current Limitations

Bitcoin Script: A simple programming language used to verify Bitcoin spending conditions, based on the UTXO (Unspent Transaction Output) model. For example, a transaction from Ryan sending 0.5 BTC to Windy requires Windy to provide the correct digital signature for spending.

Limitations of Bitcoin Script

Weak expressiveness: Lack of complex operations (multiplication, division), limited arithmetic processing to 32-bits and stack maximum of 1000 elements, making it difficult and space-consuming to create complex spending conditions.

No global state storage: Bitcoin Script cannot access data beyond the current transaction, unlike Ethereum where smart contracts store balances and state. This limits the ability to build multi-purpose applications or trustless bridges.

OP_CAT and OP_CTV upgrades

OP_CTV (BIP 119) – Introduction and potential

What is OP_CTV?: Proposed by Jeremy Rubin (2020), OP_CTV (Check Template Verify) adds covenants – binding spending conditions – to Bitcoin Script. It allows the sender to specify how the Bitcoins are spent after sending.

Application example: Ryan sends 0.4 BTC to Windy and Charlie with the condition that he will only spend it after 1 year, and locks 0.2 BTC in a self-managed vault. OP_CTV uses commitment hash to ensure transparency and security.

Benefits: Enhanced security for self-managed vaults, transparent transaction support, and expanded programmability without complex pre-signed transactions.

OP_CAT (BIP 347) – Introduction and Potential

What is OP_CAT?: Proposed by Ethan Heilman and Armin Sabouri (2023), OP_CAT allows concatenation of two data chunks in the stack, which was disabled in 2010 due to security concerns but is now possible thanks to Taproot.

Application example: Ryan creates a Bitcoin key vault in 100 blocks, uses OP_CAT to concatenate information and hash into a transaction hash, combined with CheckSig for verification.

Benefits: Increased flexibility for Bitcoin Script, support for Merkle Tree generation in Tapscript, combined with Schnorr Signatures to create non-recursive covenants, improved Lightning Network and Layer 2 bridges.

Potential applications of OP_CAT and OP_CTV

• Trustless Bridge: Connects Bitcoin Layer 1 and Layer 2 without intermediaries, reducing dependence on WBTC or cbBTC.

• Self-managed vault: Increased security for individual users and organizations.

• Lightning Network Improvements: Reduced Fees and Increased Instant Transaction Performance.

Risks and challenges

• Technical risks: Software bugs or unintended uses (like post-SegWit and Taproot inscriptions) may occur, despite extensive testing of OP_CAT and OP_CTV.

• Security concerns: Some argue that covenants can be abused to control transactions, but in reality the conditions are set by the owner and do not last forever.

• Community Consensus: The BIP approval process requires consensus from miners, developers, exchanges, and KOLs, which can extend the implementation time.

Implementation roadmap

• BIP Process:

  • Phase 1 (Idea): KOLs and communities drive awareness (like Taproot Wizards with OP_CAT).

  • Phase 2 (Evaluation): Bitcoin Core developers decide to integrate the source code.

  • Phase 3 (Activation): Miners and economic nodes vote on BIP 9, BIP 8, Speedy Trial, or Modern Soft Fork Activation.

• Forecast: HCC Ventures predicts consensus could be reached in Q3-Q4/2025, with implementation taking another 1-2 years due to the complexity of the Bitcoin network.