This document highlights some common fallacies often repeated by proponents of the 'op_cat' proposal

CATastrophy.md

Prevent the CATastrophe

This document highlights some common fallacies often repeated by proponents of the 'op_cat' proposal. My goal isn't to argue for or against op_cat, but to debunk these misconceptions and steer the discussion toward a more fact-based, rational analysis.

"It's Quantum Resistant!"

Some proponents claim that op_cat would enable quantum-resistant signatures. This is misleading because op_cat functions only within Tapscripts, which rely on a Taptweak for security. A sufficiently powerful quantum computer could potentially break the Taptweak, bypassing the op_cat script and rendering any quantum-resistant signatures useless. Thus, op_cat alone cannot enable a post-quantum signature scheme.

"Let's Enable Covenants!"

Proponents often argue that we should activate op_cat because it would enable covenants. However, op_cat only allows for a convoluted workaround to mimic covenants, and this emulation is both complex to implement and inefficient in terms of block space and transaction fees. If the goal is to enable covenants, it would be more prudent to consider well-designed covenant proposals such as TXHASH or introspection opcodes.

"It's Only 10 Lines of Code!"

A frequent argument is that op_cat is "just 10 lines of code." This is a fallacy because even minimal code changes can have catastrophic consequences. The fact that you might not immediately exploit these 10 lines does not mean that op_cat won't interfere with the broader system and its incentive structures.

In fact, one of the strongest arguments against op_cat is the difficulty in fully understanding its potential implications. It could represent one of the most significant consensus changes of any Bitcoin Improvement Proposal, radically expanding Bitcoin's smart contract capabilities. Since it's impossible to predict all the consequences of activating op_cat, we cannot confidently assert its safety.

"It doesn't introduce MEV!"

Some proponents argue that op_cat wouldn't affect miner incentives because Automated Market Makers (AMMs) are incompatible with current token standards. This, however, is a narrow view. AMMs are just one of many potential developments that could disrupt Bitcoin's incentive structure. Moreover, the design space for op_cat-based token standards and DeFi applications is largely unexplored, and we cannot foresee all the innovations that might emerge and how they affect MEV.

Item 4 may be better phrased as "It doesn't introduce MEV!"

AMMs in particular are an argument against CAT, and "You can't build an AMM!" is a retort to that criticism rather than a core argument for CAT. The overall absence-of-MEV claim is more valid here than the specific AMM framing is

Good point! Changed it.

Thanks for writing this up. I've been meaning to write up something similar.

I agree with you on the facts, but I see some of these as arguments for, rather than arguments against, CAT.

"Let's Enable Covenants!"

However, op_cat only allows for a convoluted workaround to mimic covenants, and this emulation is both complex to implement and inefficient in terms of block space and transaction fees.

Rather than a negative I see this as the biggest benefit of CAT to covenants. Bitcoin is unlikely to get a redo on an covenant specific opcode, so it is important that we get the covenant opcode right the first time. The biggest risk here is that the covenant specific opcode misses critical use case or desired functionality we didn't know we needed. There is a chicken and the egg problem here. Most businesses and researchers aren't going to invest significant resources into covenants until they are sure Bitcoin will support them, but getting a covenant specific opcode right requires actually that sort of activity.

This provides several benefits to covenants:

1. CAT solves this chicken and egg problem. CAT enables covenants without being a covenant specific opcode. This means people can build businesses and complex protocols once CAT if enable and then we can use that information to design the right covenant specific opcode. CAT let's us learn lessons early.
2. CAT lets us patch issues in covenants. Let's say after merging some covenant opcode someone invents a protocol that the covenant opcode can't support. CAT makes covenants more flexible letting us patch this missing feature.
3. CAT lets us put our toes in the covenant water without fully committing. I'm in favor of covenants, but not everyone is. Say we discover that covenants hurt decentralization, CAT covenants are expensive and clunky which limits the damage. On the other hand, if CAT covenants are being used and the sky isn't falling, the case for enabling a covenant specific opcode becomes easier.

"It's Only 10 Lines of Code!"

This is a fallacy because even minimal code changes can have catastrophic consequences. The fact that you might not immediately exploit these 10 lines does not mean that op_cat won't interfere with the broader system and its incentive structures.

I couldn't agree more!

This "10 lines of code" argument should only be used to argue that the implementation of CAT is less likely to have bugs. CAT by being a small change is less likely to have bugs than say a 1000 line change consensus code in Bitcoin. No one should be using this argument to argue about incentive effects of CAT.

"It doesn't introduce MEV!"

We must carefully consider the MEV implications of any change to Bitcoin. I don't have much to say specifically about CAT right now. I'm still collecting my thoughts with regard to CAT and MEV. I plan to write more about it in the future.

I do want to make the point that we can't escape MEV even if we don't add any opcodes. Optimistic layer two protocols create opportunities for MEV through systems like watchtowers and miner bribery. Beyond this, other blockchains can introspect into Bitcoin. While this isn't currently being done at scale, it seems likely the MEV opportunities for bitcoin miners will grow regardless of any new opcodes.

"It's Quantum Resistant!"

I agree that CAT lets you build quantum resistant Lamport Signatures in Bitcoin, but Lamport Signatures in Tapscript does not provide quantum resistance by itself.

This is misleading because op_cat functions only within Tapscripts, which rely on a Taptweak for security. A sufficiently powerful quantum computer could potentially break the Taptweak, bypassing the op_cat script and rendering any quantum-resistant signatures useless.

There are two potential problems with using CAT to make Bitcoin transactions quantum resistant:

• Taproot Tapscript-Spend path (Maybe Quantum Resistant): The tapscript taptweak is generally assumed to be quantum secure under the preimage resistance of the hash function used to compute the tweak. While this assumption is reasonable, no one has provided a security proof of the quantum resistance of the tapscript taptweak. Without such a proof the question of the quantum resistance of tapscript-spends can not be said to be decided.
• Taproot Key-Spend path (Confirmed Vulnerable to Quantum Attacks): An attacker with a sufficiently powerful quantum computer could bypass the taproot script spend-path by finding the discrete log of the taproot output and thus spending the output using the key spend-path.

There is some nuance here. If we assume that tapscript-spend path is quantum resistant and the key-spend if disabled, then CAT would enable quantum resistant transactions.

Let's say CAT is activated on Bitcoin. People could create quantum resistant signatures as standard wallet behavior. These transactions would not be quantum resistant. If a quantum computer capable of breaking bitcoin signatures was on the horizon, the bitcoin community could perform a softfork that disables taproot key-spends making these transactions quantum resistant. Users who already had quantum resistant CAT based signatures wouldn't need to take any action. Users who didn't have a CAT based quantum resistant signature in their outputs would need to spend to a quantum resistant output before the softfork.

Personally I don't think quantum resistance is a strong reason to enable CAT. If we enabled CAT for other reasons, this is nice to have.