Evaluating Bitcoin upgrade proposals

Getting your Trinity Audio player ready...

This post was first published on Medium.

This is the rationale for our opinion shared in Covenants Support Wiki.

Criteria

The original goal of Script was to provide users with a sufficiently general scripting language, empowering them to create and experiment with their own types of transactions. In essence, the aim was to give users the freedom to design and program their own on-chain assets.

Satoshi has warned against scoped proposals since the very beginning, each addressing only specific use cases. These proposals aim to enable limited functionalities rather than tackling the broader need for expressivity and programmability required for Bitcoin’s long-term scalability. Any proposal that has been designed to enhance a single, narrow feature is thus considered undesirable. Not taking this approach has led to stagnation in discussions — no one is fully satisfied because each proposal fails to address the diverse use cases others want to see implemented. Instead of engaging in constant debates over incremental improvements, we should explore the entire spectrum of functionality Bitcoin needs. By doing so, we can move beyond the current cycle of conflict and create a more unified vision for Bitcoin’s future.

Script, like any other programming languages, is never designed solely for a single application or to create just one program. It is built to support fundamental building blocks. The core design of Script does not necessarily dictate how it will be used but ensures that its components are not combined in ways that harm users. If new proposals enhance the trust model for end users without significantly worsening their impact on system incentives, they do not introduce any substantial new risks and thus can be considered for activation.

We employ the criterion of generality to evaluate several opcode proposals. We would also prefer a proposal that has demonstrated sufficient interests and security.

OP_CAT

Most general

OP_CAT is the single most powerful and general-purpose opcode proposal, from our six years of experience working with Bitcoin Script full time since 2018. It is also the only opcode introduced by Satoshi himself.

Covenant is only one of the numerous use cases it enables, including:

• Merkle Trees
• Vaults
• Recursive Covenants
• Drivechain
• Trustless L2 bridge
• Zero-knowledge proof

A comprehensive list can be found here.

Most usage

BIP 118 (SIGHASH_ANYPREVOUT, APO) and BIP 119 (OP_CHECKTEMPLATEVERIFY, CTV) have been enabled on signet for nearly two years, since late 2022. More recently, BIP 347 (OP_CAT) was activated, having been available for six months. Despite of being active for only 1/4 of the time, there are significantly more on-chain transactions utilizing OP_CAT (74K) compared to APO (1K) or CTV (16), translating to 300X and 18500X more usage in a given period.

• CTV, APO, CAT activity on signet

Most recently, Fractal Bitcoin, a scaling sidechain reusing Bitcoin’s codebase, has integrated OP_CAT to enhance its programmability. By reactivating this opcode, Fractal Bitcoin can support more sophisticated smart contract functionalities, which are not feasible on the Bitcoin mainnet without such enhancements. This includes the possibility of creating and managing tokens directly on the blockchain through protocols like CAT20, which are validated by miners and enforced by smart contracts at consensus layer. They providing levels of programmability, security and decentralization absent in BRC20/Runes. In three months, developers have created decentralized applications (dApps) like DEX, voting, decentralized wrapped BTC, and pump.fun. More applications are coming. Tens of millions of transactions have been generated in merely three months, representing millions of dollars of real value assets, rather than assets of no value on signet.

OP_CAT has seen enormously more interest from developers and users in the real world, than any alternative opcode.

Most battle-tested

OP_CAT was reintroduced to Bitcoin Cash (BCH) during the network upgrade in 2018 and later in BSV. The Liquid Network has OP_CAT since its inception, besides Fractal. There have been tens of millions of transactions using it and there has been zero exploit because of it.

Common misconceptions

1. OP_CAT is “inefficient”: this is because OP_CAT is generic and not tailored to a specific use case like covenant. Efficiency can be improved after a use case is demonstrated to be frequently used, by introducing dedicated opcodes. Premature optimization is the root of all evil.
2. OP_CAT causes MEV: the root cause of most of MEV, if not all, in Bitcoin is Replace-By-Fee (RBF). That is why mempool sniping is prevalent today even without OP_CAT. There is no sufficient evidence to show OP_CAT will substantially increase MEV, after 6 years of running on other Blockchains worth billions.
3. OP_CAT is difficult to reason about: so is every other opcode, since they are low-level assembly. In practical, you need a high-level programming language, such as sCrypt, to abstract the opcodes away, just like you program Ethereum smart contracts using Solidity, not EVM opcodes directly.
4. OP_CAT causes centralization: the reality is that more flexible Layer 2 solutions require a more flexible base layer, which is enabled by OP_CAT. The only alternative to this is relying on trusted third parties, so OP_CAT can help decentralization as we have witness in miner-validate tokens like CAT20, without centralized indexers.

OP_CSFS/CHECKSIGFROMSTACK

OP_CSFS is a proposed Bitcoin opcode that would enhance Bitcoin Script by allowing a signature to be verified against arbitrary data, rather than the entire transaction data. It can be emulated using OP_CAT and OP_CHECKSIG. A standalone opcode OP_CSFS can be more efficient. OP_CAT needs to be activated together to parse signed serialized data¹. For example, an oracle can attest to BTC price at a specific time, who signs the serialized price and timestamp jointly.

OP_CTV/CHECKTEMPLATEVERIFY

OP_CTV enforces funds to be spent only through a transaction that precisely matches a predefined template. It has several shortcomings.

1. It only allows a limited, thus not general, form of covenant, which was specifically designed to enhance the functionality of pre-signed transaction chains.
2. It does not enable recursive covenant.

Others

We cover some other proposals briefly below.

• OP_VAULT: was designed specifically to enable vault, which can be implemented by OP_CAT without OP_VAULT
• TXHASH: a strict superset of OP_CTV, but still limited in itself. OP_CAT can make it more powerful by introspecting not only the current spending transaction, but also its parent transactions.
• ANYPREVOUT (SIGHASH_APO): tailored specifically to optimize Lightning.

***

[1] OP_CAT can be used to split a bytestring A into substring B and C, by passing B and C and verifying they concatenate to A.

Watch: sCrypt wants to bring hackathon initiative to more people