introduction
You may have heard about re-enabling OP_CAT as a potential upgrade to Bitcoin's script language. Depending on where you get the news, OP_CAT has been called “only 10 lines of code”, “best way to enable test covenants”, “very powerful”, “dangerous and leads to centralization of miners”, or “guaranteed to lead to “Into a controversial soft fork.” I will show that all of these points of view are wrong. OP_CAT is very useful and can be used as a pledge, not (alone) the best next step for Bitcoin. Nothing more and nothing less.
To make this case, I will explore several (seemingly disjointed) topics, some of which were new to me just a few short months ago. I will try to arrange this in a way that provides the necessary background in one place.
How and what OP_CAT does
Introspection with CAT
Let's deal with the burning question that many ask when they are exposed to OP_CAT for the first time. How can a few lines of code that combine two stack elements into one (AB CAT -> AB) enable anything interesting? Andrew Poelstra has eloquently explained in Recently Interviewsand posted a ridiculous, concise explanation:
Bitcoin is a bit weird, so it can also split things. SHA256 then allows us to undo the hash. Because cryptography is just math and we know how to crunch it, CAT allows us to extract the hash from signature verification. As a result we can examine anything hashed within the signature…
— Rearden 🍯🦡 🦢 | Embrace Forks (@reardencode) May 17, 2024
Since Bitcoin script is a strict verification language, each opcode can be used forward or backward. The script can be given a hash and require a raw image, or given a raw image and require a hash using OP_SHA256. This insight gives us the first two parts of how OP_CAT charters work.
If a Bitcoin script has access to the hash of the transaction it is verifying, it would require that the spending package provide a pre-hash image, hash it in any way the script requires, and then validate any particular part of that pre-image. This is exactly what a covenant is – validating the part of the transaction that spends some Bitcoin.
That's great, but Bitcoin doesn't have an operating code like… OP_TXHASH Grants the script access to the transaction hash. Here we benefit from BIP340 Schnorr Signature verification formula to ask the user to provide the hash. If the user provides a value that will be a valid transaction hash if the script concatenates byte 0x00 to its end, this value will also be part of a valid BIP340 signature (with some other parameters fixed) if the script concatenates byte 0x00 to its end. Byte 0x01 for that.
Combining these techniques enables OP_CAT to verify which part of its spending transaction can be signed, and even go back to the original transactions in some limited ways. With some careful programming, one can build Perfect cabinets, CATFMAnd more.
Other uses of CAT
But we shouldn't. Building these things with OP_CAT makes it 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, and merging data for signature verification with OP_CHECKSIGFROMSTACKAnd more.
Problems with the cat
Now that we know what CAT does, what's the problem? Why did people (including me) say he was a dangerous monster? Using the introspection technique described above, CAT enables two specific creations: hash collaterals, and (presumably) automated market makers (AMMs). Until recently, both were considered high risks to bring a centralized MEV to Bitcoin.
MEV, MEVil and Centralized Mining
The term MEV (mining extractable value) is a bit confusing. In the simplest explanation, this would include transaction fees, which of course we want to pay to miners to help ensure the security of Bitcoin long into the future. MEV is generally used to indicate the additional value that miners can extract from their blocks beyond the fees visible on the public relay network. This can come in the form of out-of-band payments, miners participating in contracts and rearranging transactions in ways to their advantage, or even outright theft of goods and services by the miners doing the mining, as they reorganize and spend a confirmed payment to the merchant. All of these forms of MEV can be considered generally bad for network participants, as miners use their position in the network to their own benefit at the expense of other network participants. However, MEV alone does not represent a systemic problem by driving mining centralization, but rather is only a local problem for the specifically affected participants.
MEVil is a term sometimes used for the MEV that drives the centralization of miners – I prefer the term MEV centralization and will use it from now on. Several things are necessary to convert an MEV into a centralized MEV:
- It must be difficult enough to extract that that an open source block template generator couldn't reasonably extract it
- The total extractable value should grow with the miner's Bitcoin hash rate
- The extractable value must justify the cost of extraction
If all these requirements are met, only a large enough miner will have the incentive to start mining MEV. Once they do, they will be able to outpace the growth of their smaller peers thanks to the additional revenue extracted. The more expensive it is to mine a MEV (to the point where it's not worth it to any miner) the worse the central pressure it creates.
Avoiding MEV centralization is simple (in a sense): making sure that any MEV opportunities that exist on Bitcoin are either so easy to mine that everyone is doing it or the cost of extracting them is more than they're worth (either because they're too small or because they're too expensive).
For more information, check out @TheBlueMatt's Last post.
Hashrate collateral (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 perfect solution for scaling Bitcoin. The idea was simple in theory: Bitcoin blocks should remain limited in size for all the usual decentralization reasons, but we could connect sidechains to Bitcoin and those blocks could have faster blocks, bigger blocks, more calculations, or whatever. However, in practice, implementing the sidechain was not that easy. Bitcoin's final settlement is mainly related to proof of work, which is an irrefutable cost of reordering transactions, so how does the sidechain inherit this? 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 to such sidechain systems: either they are relatively unused (and therefore useless) or they become widely used and become an actual block size increase for Bitcoin. An actual increase in block size of this type is a form of centralized MEV as only larger miners will be able to cost-effectively participate in the additional revenue opportunities provided by large, complex side blocks.
Hashrate collateral, which can be created using OP_CAT, is a small part of Drivechains' proposals. This is a system for restricting sidechain withdrawals using a counter whose value can only be changed by miners, starts with a high value, and must reach zero before sidechain withdrawals can be processed. This is allegedly a “trustless” transfer from a sidechain, but in reality it creates a consortium of miners that controls all the bitcoins on the sidechain.
Since the development of Drivechains proposals, it has become common (to our detriment) to refer to any proposal that can be used to create a withdrawal based on a miner-controlled counter as “Drivechains.” Hopefully it's clear at this point why this awkward acronym is unhelpful – chains of command are either worthless or dangerous, but hash rate guarantees are just a way to transfer control of the outcome of some transactions to the implicit union of miners.
Tokens and AMMs
Symbols
For reasons that won't be entirely clear to me, humans love good code (or bad code or just good code). Almost since the inception of Bitcoin, there has been talk about how other tokens could be included in the protocol, from Colorful coins And Opposite partyto the latest Root assets And Runes. All of these protocols have one thing in common: they require an external index of Bitcoin transactions that has knowledge of external data or processes data from the sequence of Bitcoin transactions in order to determine token transfers within the protocol. The salient point of this article is that Bitcoin locking scripts are completely unaware of the existence of tokens, and even the Bitcoin nodes that validate transactions are not aware of the tokens (i.e., even if the Bitcoin locking script has full access to the Bitcoin pool full UTXO, was unable to detect the status of any of these codes).
Automated Market Makers (AMMs)
In other blockchain systems, it is common to use contracts known as AMMs (for example) to tie the ratio between two tokens by buying and selling at a fixed price. The rules that can be encoded in AMM are beyond the scope of this article. Suffice it to say that AMMs create massive opportunities for MEVs and because of the special exchange relationships needed to maximize returns on those MEVs that also centralize MEVs. This is often used as an argument against creating more expressive Bitcoin scripts – we really want to avoid exposing the Bitcoin network to centralized MEV fluctuations. However, as I described above, there is no practical way for Bitcoin scripts, no matter how expressive, to evaluate the state of any non-Bitcoin token. Bitcoin scripts cannot locate rare sat. They cannot find the balance of the rune. They cannot determine the origin of Taproot.
Without access to any information about the disposition of non-Bitcoin assets, the entire concept of a Bitcoin script-based AMM becomes illogical. Token locations can be authenticated by a signature from an oracle, but oracle certificates do not generate an AMM. They can be used to facilitate specific manual trades, but are not a solid automated system. Moreover, such an oracle-based system could be built today without any changes to Bitcoin.
Conclusion
As you can see, the CAT is not a scary beast. It's not a monster at all. She has no infinite ability and no magical powers. It's just a little launch code that can be very useful. One thing we might want to avoid is activating OP_CAT without another way to perform transaction checking, such as OP_TXHASH, OP_TX, or both. Even enabling it with LNHANCE is an improvement over OP_CAT alone because it reduces the size and complexity of scripts needed to achieve many OP_CAT introspection protocols.
I think at this point, "CAT offers endless everything" Reduced to ~nil.
It presents useful introspection in a bad way that no one should use. To help people not use it, we should enable CAT 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. The opinions expressed are entirely their own and do not necessarily reflect the opinions of BTC Inc or Bitcoin Magazine.
