Introduction
You may have heard about re-enabling OP_CAT as a potential upgrade for bitcoin’s script language. Depending on where you get your news OP_CAT has been called “only 10 lines of code”, “the best way to enable experimentation with covenants”, “too powerful”, “dangerous and leading to miner centralization”, or “guaranteed to lead to a contentious soft fork”. I’m going to make the case that all of these perspectives are mistaken. OP_CAT is very useful, can be used as a covenant, and not (alone) the best next move for bitcoin. Nothing more, and nothing less.
To make that case, I’m going to explore several (apparently disjoint) topics, some of which were new to me a few short months ago. I’m going to try and arrange this in a way that provides the necessary background in one place.
How and What OP_CAT Does
Introspection with CAT
Let’s tackle the burning question that many have when first exposed to OP_CAT. How can a few lines of code that combine two items from the stack into one (A B CAT -> AB) possibly enable anything interesting? Andrew Poelstra has eloquently explained in recent interviews, and I posted a silly and brief explanation:
Bitcoin is a bit weird, so it can also split things. Then SHA256 lets us undo hashes. Then because cryptography is just math and we know how to grind, CAT lets us extract a hash from a signature verification. And as a result we can inspect anything hashed inside a signature…
— Rearden 🍯🦡 🦢 | embrace forks (@reardencode) May 17, 2024
Because bitcoin script is strictly a verification language, each opcode can be used in forward or reverse. A script can be given a hash and require a preimage, or given a preimage and require a hash using OP_SHA256. This insight gives us the first two parts of how OP_CAT covenants work.
If a bitcoin script could get access to a hash of the transaction it’s verifying, it could require that the spend stack provide the hash preimage, split in whatever way the script requires, and then validate any particular part of that preimage. This is exactly what a covenant is – validating a part of the transaction spending some bitcoin.
That’s great, but bitcoin doesn’t have an opcode like OP_TXHASH to give the script access to the transaction’s hash. Here, we take advantage of the BIP340 Schnorr signature verification equation to require that the user provide the hash. If the user provides a value that will be a valid transaction hash if the script concatenates the byte 0x00 to the end of it, that value will also be a part of a valid BIP340 signature (with certain other parameters fixed) if the script concatenates the byte 0x01 to it.
Combining these techniques, enables OP_CAT to check any part of its spending transaction that can be signed, and even to look back at its parent transactions in some limited ways. With some careful codecraft, one can build Purrfect Vaults, CatVM, and more.
Other uses for CAT
But we shouldn’t. Building these things with OP_CAT results in difficult to maintain abominations. Instead, we should use OP_CAT for what it’s good for, and there’s plenty of that: It enables the equivalent of OP_CHECKSEPARATESIG, checking Merkle inclusion proofs, combining data for signature verification with OP_CHECKSIGFROMSTACK, and more.
Problems with CAT
Now that we know what CAT does, what’s the problem? Why have people (myself included) said that it’s a dangerous beast? Using the introspection technique described above, CAT enables two specific constructions: Hashrate escrows, and (supposedly) automated market makers (AMMs). Until recently, both of these were considered significant risks of bringing centralizing MEV to bitcoin.
MEV, MEVil and Miner Centralization
The term MEV (Miner Extractable Value) is a bit confusing. In the plainest interpretation it would include transaction fees, which of course we want paid to miners to help ensure the security of bitcoin long into the future. MEV is generally used to mean additional value that miners can extract from their blocks beyond the fees visible on the public relay network. This could come in the form of out of band payments, miners participating in contracts and reordering transactions in ways that favor themselves, or even outright theft of goods and services by miners mining blocks that reorg and double spend a confirmed payment to a merchant. All of these forms of MEV can be considered generally bad for the participants in the network, as the miners are using their position in the network to their own benefit at the expense of other network participants. However, MEV alone does not present a systemic problem by driving miner centralization, only a local problem for the specifically impacted participants.
MEVil is a term that is sometimes used for MEV which drives miner centralization – I prefer the term centralizing MEV and will use it going forward. Several things are necessary to change MEV into centralizing MEV:
- It must be sufficiently difficult to extract that an open source block template builder cannot reasonably extract it
- The total value extractable must grow with a miner’s bitcoin hash rate
- The extractable value must justify the cost of extraction
If all of these requirements are met then only a sufficiently large miner will have the incentive to begin extracting the MEV. Once they do, they will be able to outpace their smaller peers’ growth thanks to the additional revenue extracted. The more costly the MEV is to extract (up to the point where it is not worth it for any miner) the worse the centalizing pressure it creates.
Avoiding centralizing MEV then is (in a sense) simple: Ensure that whatever opportunities for MEV exist on bitcoin are either so easy to extract that everyone does it or cost more to extract than they’re worth (either because they’re so small or because they’re so costly).
For more information, check out @TheBlueMatt’s recent post.
Hashrate Escrows (née Drivechains)
Many years ago (before the Lightning Network or ideas like Ark, Timeout Trees, roll-ups, BitVM, or CatVM) sidechains were considered the ultimate scaling solution for bitcoin. The idea was conceptually simple: bitcoin blocks must stay limited in size for all the usual decentralization reasons, but we can attach sidechains to bitcoin and those can have faster blocks, bigger blocks, more computation, or whatever. In practice, however, implementing sidechains was not so easy. Bitcoin’s final settlement is fundamentally tied to proof of work, an unfalsifiable cost to reorder transactions, how does a sidechain inherit that? Also, how can bitcoin be transferred to and from the sidechain? The best known proposal to answer these two questions is called Drivechains (BIPs 300 and 301). I won’t bore you with the details of Drivechains, but suffice it to say, there are only two outcomes of such sidechain systems: Either they are relatively unused (and therefore useless) or they are widely used and become a de facto block size increase for bitcoin. A de facto block size increase of this sort is a form of centralizing MEV where only larger miners will be able to cost effectively participate in the additional revenue opportunities offered by the potentially large and complex sidechain blocks.
Hashrate escrows, which can be built with OP_CAT, are one small part of the Drivechains proposals. This is a system of restricting withdrawals from sidechains by using a counter whose value can only be changed by miners, starts at a high value, and must reach zero before a sidechain withdrawal can be processed. This is claimed to be a “trustless” transfer out from a sidechain, but actually creates a federation of miners with control of all bitcoin held in sidechains.
Since the development of the Drivechains proposals, it has become (to our detriment) common to refer to any proposal which can be used to create a withdrawal predicated on a miner-controlled counter as “Drivechains”. Hopefully it clear at this point why this inappropriate shorthand is unhelpful – Drivechains are either worthless or dangerous, but hashrate escrows are merely a way to transfer control the outcome of some transaction to the implicit federation of miners.
Tokens and AMMs
Tokens
For reasons that will never be entirely clear to me, humans love a good token (or a bad token or really just tokens). Nearly from the beginning of bitcoin there has been talk of how to embed other tokens into the protocol, from Colored Coins and Counterparty, to the more recent Taproot Assets and Runes. All of these protocols have one thing in common: They require an external index of bitcoin transactions that either has knowledge of external data or processes data from the sequence of bitcoin transactions in order to determine the transformations of tokens within the protocol. The salient point for this article is that bitcoin locking scripts are completely unaware of the existence of the tokens, and even bitcoin nodes that validate transactions are unaware of the tokens (i.e. even if a bitcoin locking script had full access to the complete bitcoin UTXO set, it could not discover the state of any of these tokens).
Automated Market Makers (AMMs)
On other blockchain systems it is common for contracts known as AMMs to be used to (for example) peg the ratio between two tokens by buying and selling at a fixed price. The rules that can be encoded in an AMM are beyond the scope of this article. Suffice it to say that AMMs create huge opportunities for MEV and because of the private exchange relationships needed to maximize the returns on that MEV also centralizing MEV. This has often been used as an argument against building more expressive bitcoin scripts – we genuinely do want to avoid exposing the bitcoin network to the vagaries of centralizing MEV. However, as I’ve described above there simply is no practical way for bitcoin scripts, no matter how expressive, to evaluate the state of any token other than bitcoin. Bitcoin scripts cannot locate a rare sat. They can’t find a Rune balance. They can’t identify a Taproot Asset.
Without access to any information about the disposition of non-bitcoin assets, the entire concept of a bitcoin script based AMM ceases to make sense. Token locations can be attested to by a signature from an oracle, but oracle attestations do not make an AMM. They can be used to facilitate specific manual trades, but not a durable automated system. Moreover, such an oracle-based system could be built today with no changes to bitcoin.
Conclusion
As you can hopefully see, CAT is not such a frightful beast. It’s not really much of a beast at all. It has neither infinite capability nor magical powers. It’s just a little opcode that can be very helpful. The one thing we probably want to avoid is activating OP_CAT without another way to do transaction introspection, such as OP_TXHASH, OP_TX, or both. Even enabling it with LNHANCE is an improvement on OP_CAT alone because it reduces the size and complexity of the scripts needed to achieve many OP_CAT introspection protocols.
I think at this point, the "CAT introduces infinite everything" has been reduced to ~nothing.
It introduces helpful introspection in a shitty way that nobody should use. To help people not use it, we should enable CAT along with TXHASH or similar.https://t.co/nvnxYn66Um https://t.co/1Ag5TwjuUw
— Rearden 🍯🦡 🦢 | embrace forks (@reardencode) May 17, 2024
This is a guest post by Brandon Black. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
