Now that OP CAT is out of the bag…

Adapting to Survive and Thrive

Bitcoin Script is a FORTH-like programming language that supports a dictionary of opcodes. There are 18 constant opcodes representing integers -1, 0, 1, …, 15 and 16. There is a set of opcodes dedicated to loading data during script executions; and each is used to indicate the size of the data element. The more interesting set is the functional opcodes which include flow control, stack movement, cryptographic algorithms, arithmetic and string operations. For Bitcoin Core (BTC), however, most of the opcodes related to arithmetic and string operations are disabled. OP_SIZE which determines the length of a string is the only available opcode for strings. Arithmetic operations are limited to basic addition and subtraction on 32-bit integers, capping at a maximum value of 65,536. In short, as things stand, there is no fun playing with these opcodes.

This situation was mainly caused by concerns over security. However, there was only one concrete vulnerability identified, namely, denial of service (DOS) attack. The rest of the concerns, to say the least, are not evidence-based and more about the belief that Bitcoin should stay as primitive as possible. Despite the limitations on opcodes, Bitcoin still enjoys its supremacy in market capitalisation even after Ethereum dominated the smart contract and ICO markets. Though just before the last halving in April 2024, token standards such as Ordinal and BRC20 started to emerge on BTC. This is clearly an adaptation to the market: Bitcoin needs to evolve to become fit enough to survive and thrive.

Challenging the Status Quo — OP_CAT

The status quo of the BTC community is challenged by BIP347 which proposes to re-enable OP_CAT, an opcode that concatenates two strings. The original motivation was to give developers the ability to create complex rules for spending transactions in Bitcoin Script (often referred as covenant transactions), unlocking potential new use cases like self-propagating smart contracts. Its usefulness is demonstrated by the recent success of a new token protocol called CAT20.

The support for re-enabling OP_CAT grew significantly with the realisation that OP_CAT can enable implementations of Zero-Knowledge Proof (ZKP) verification (in the form of STARKs). This is a big and pleasant surprise to many as it shows that BTC is just one opcode away from having smart contract capability comparable to Ethereum. However, the truth is less convenient than it appears. The implementation of ZKP verification using OP_CAT may result in less economically viable or insecure solutions for many real-world use cases.

The Debate

Here is a quick summary of the arguments for and against re-enabling OP_CAT on BTC.

For:

1. It brings more functionalities such as covenant transactions and on-chain ZKP verifications.

2. It requires minimal change.

3. It may bring post-quantum security.

Against:

1. It violates the belief that Bitcoin should stay simple.

2. It introduces security vulnerabilities or security risks.

To put my two sats in the debate, I would say the choice is more of a spectrum than it is binary, ranging from “no change at all — stay primitive” to “enable all opcodes — stick to original design”, or even extending to “add new opcodes — keep innovating”. What about re-enabling “OP_MUL” for integer multiplication too? What about “OP_MOD” which can be useful for many cryptographic schemes? What about adding a new opcode OP_SNARKVERIFY for ZKP verification (I would love that :P)? Enabling OP_CAT is just a choice among many. Some would probably argue “but that is the best deal in a decade: minimal change to make a huge difference”. Personally, I agree with this argument, but the implicit cost-benefit analysis behind that statement is in fact quite subjective.

I hope by now you can see that this is about striking a balance between opportunities and risks (or conventional beliefs). Striking a balance is difficult and it requires iterations. Fortunately for BTC, there are three real-world examples to gather information from.

Learning From Others

The first one is Bitcoin Cash (BCH). In 2019, they introduced a new opcode to allow verification of digital signatures on any data element on the stack, OP_CHECKDATASIG, which enabled use cases that were deemed valuable at the time. While most people would find it useful, it did not pick up any traction since its introduction. (If you google OP_CHECKDATASIG, you can find the top search results are from 5 years ago…)

The second example is Fractal Bitcoin, a blockchain that is launched in early 2024. It uses all the opcodes that BTC uses and OP_CAT. Its popularity is reflected by its price since launch, dropping from $30 to $6, with only one major use case that is quite successful — CAT20. The developers seem to have enjoyed the excitement of using OP_CAT to create new use cases, but shortly after, they crave more.

The third example is Bitcoin Satoshi Vision (BSV), which has all the functional opcodes available as in the original Bitcoin node software including arithmetic on big integers. This allows many cryptographic operations to be performed during script execution. The main tactic BSV adopts to mitigate DOS attacks is to put a limit on memory usage for script execution. The limit is policy-based in the sense that mining nodes can adjust the limit based on their preferences but must accept other’s policy limit during block validation. Together with other policy parameters, BSV essentially passes the power from developers to miners who actually have stake in the game. The miners can adjust those parameters to be more suited for the market, and more importantly, be more adaptable for the ever-changing nature of the market. Covenant transactions on BSV mainnet can be found back in 2021 if not earlier. A Groth16 verification with bilinear pairing operations can be implemented under 500 KB, you can find the full script on the mainnet. This is not an optimistic approach or using dummy security parameters. If you want to experience the power of “OP_MUL”, “OP_MOD” and the support for big integers, you can try it out yourself using zkScript.

Possibility vs Feasibility

OK, that was a tiny little bit bias with the intention to promote the wonderful work our team has produced. Coming back to the serious debate, if BTC wants to stay uniquely simple while all other blockchains innovate, it is unlikely for it to be economically sustainable in the long run after a couple more halvings. Enabling OP_CAT is a good opportunity to initiate a wider discussion on how BTC should move forward.

If your conclusion is to have a simple and secure blockchain that is functional just enough to support a diversified all-rounder Layer 2 or overlay networks, then I would recommend enabling OP_MUL, OP_MOD and BigNum support.

OP_CAT can make things possible, but not necessarily feasible. Why stop at being possible? Go for feasibility — real world applications! What do you think? Please share your thoughts in the comments!