OP_CAT and infinite nothingness

introduction

You may have heard about re-enabling OP_CAT as a potential upgrade to the Bitcoin scripting language. Depending on where you get your news, OP_CAT is “just 10 lines of code”, “the best way to enable contract experimentation”, “too powerful”, “dangerous and leads to miner centralization”, or “controversial” “soft fork”. I would argue that all of these views are wrong. OP_CAT is very useful and can be used as a covenant (alone) rather than the best next move for Bitcoin. Nothing more, nothing less.

To make that case, I will explore several (admittedly separate) topics. Some of them were new to me just a few months ago. We’re trying to organize it in a way that provides all the background you need in one place.

Functions and methods of OP_CAT

Self-reflection through CAT

Let’s address the questions many people have when first exposed to OP_CAT. How can a few lines of code combining two items on the stack into one (AB CAT -> AB) make something interesting possible? Andrew Poelstra explained it eloquently in a recent interview, and I posted a stupidly simple explanation.

Because Bitcoin is a little weird, it can also split things. SHA256 then allows you to undo the hash. Then, since encryption is just math and we know how, CAT allows us to extract the hash from the signature verification. As a result, we can inspect everything hashed inside the signature.

— Reardon 🍯🦡 🦢 | Accept fork (@reardencode) May 17, 2024

Bitcoin Script is strictly a verification language, so each opcode can be used in either the forward or reverse direction. The script may be given a hash and require a pre-image, or it may be given a pre-image and require a hash using OP_SHA256. This insight provides the first two parts of how the OP_CAT covenant works.

If your Bitcoin script has access to the hash of the transaction you are verifying, your spending stack may need to provide a hash pre-image, split it in the way your script requires, and then verify certain parts of that pre-image. This is the contract. It uses Bitcoin to verify part of a transaction.

That’s great, but Bitcoin doesn’t have an opcode like OP_TXHASH that gives script access to the transaction hash. This utilizes the BIP340 Schnorr signature verification equation to require the user to provide a hash. If the user provides a value that will be a valid transaction hash if the script concatenates byte 0x00 to the end of that value, the script will append byte 0x01 to it.

Combining these techniques allows OP_CAT to see all parts of a spending transaction that can be signed and even look back at parent transactions in some limited way. With careful code crafting, you can build Purrfect Vault, CatVM, and more.

Other uses for CAT

But we shouldn’t do that. Building these things with OP_CAT makes Abomination difficult to maintain. Instead we should use OP_CAT for good purposes. Enables equivalent functionality with OP_CHECKSEPARATESIG, Merkle inclusion proof verification, data binding for signature verification with OP_CHECKSIGFROMSTACK, etc.

CAT questions

Now that you know what CAT does, what’s the problem? Why did people (including myself) say it was a dangerous beast? Using the self-checking technology described above, CAT enables two specific configurations: hashrate escrow and (possibly) automated market maker (AMM). Until recently, both of these were considered significant risks to centralizing MEV into Bitcoin.

MEV, MEVil and miner centralization

The term Miner Extractable Value (MEV) is somewhat confusing. The simplest interpretation would include transaction fees. Of course, we want to pay miners to ensure the security of Bitcoin for a long time. MEV is commonly used to mean the additional value miners can extract from their blocks beyond the fees seen on public relay networks. This can manifest itself in the form of out-of-band payments, miners participating in contracts and reordering transactions in their own favor, or even outright theft of goods and services by miners mining blocks, reorganizing and double-spending confirmed payments to sellers. It may appear in the form of: All these forms of MEV can generally be considered bad for network participants. This is because miners use their position in the network for their own benefit at the expense of other network participants. However, MEV alone does not cause systemic problems by promoting miner centralization; it only creates local problems for specifically affected participants.

MEVil is a term sometimes used for MEV, which promotes miner centralization. I prefer and will continue to use the term MEV centralization. Changing MEV to MEV centralized requires a few things:

1. The extraction must be sufficiently difficult that an open source block template builder cannot reasonably extract it.
2. The total extractable value should increase with the miner’s Bitcoin hash rate.
3. The extractable value must justify the cost of extraction.

If all of these requirements are met, only sufficiently large miners will have an incentive to start extracting MEV. Once you do that, you will outpace the growth of your smaller peers thanks to the additional revenue generated. The more expensive it is to extract MEV (to the point where it is worthless to any miner), the more centralizing pressure it creates.

Avoiding centralizing MEV is (in a sense) simple. We need to make sure that the opportunities for MEV that exist in Bitcoin are either easy for everyone to extract, or cost more to extract than they are worth (either because they are too small or too small). Because the price is too expensive).

Check out @TheBlueMatt’s recent post for more details.

Hashrate Escrow (formerly Drivechain)

Many years ago (before the Lightning Network or ideas like Ark, Timeout Trees, Rollup, BitVM or CatVM), sidechains were considered the ultimate scaling solution for Bitcoin. The idea was conceptually simple. Bitcoin blocks should be limited in size for all the usual decentralization reasons, but you can connect sidechains to Bitcoin, which can have faster blocks, larger blocks, more computations, etc. However, actually implementing a sidechain was not that easy. The final payment in Bitcoin is fundamentally tied to proof-of-work, or the unforgeable cost of reordering a transaction. How do sidechains inherit this? Also, how can I transfer Bitcoin to or from a sidechain? The best known proposals for these two questions are drivechains (BIP 300 and 301). I won’t bore you with the details of drivechains, but there are only two outcomes of such a sidechain system. They may be relatively unused, obsolete, or widely used, making them the de facto block size. Bitcoin increase. This kind of de facto block size increase is a form of centralizing MEV where only larger miners can cost-effectively participate in the additional revenue opportunities offered by potentially large and complex sidechain blocks.

Hashrate escrow, which can be built with OP_CAT, is one small part of the DriveChain offering. This is a system that limits withdrawals from sidechains using a counter whose value can only be changed by miners, which starts at a high value and must reach 0 before sidechain withdrawals are processed. Although this is claimed to be a “trustless” transfer from the sidechain to the outside world, it actually creates a coalition of miners that controls all Bitcoin on the sidechain.

Since the DriveChain proposal was developed, it has become common (to our detriment) to refer to any proposal that can be used to generate withdrawals based on counters controlled by miners as “DriveChain”. At this point, I hope it’s clear why this inappropriate abbreviation isn’t helpful. Drivechain is either useless or dangerous, but hashrate escrow is just a way to transfer control of the outcome of some transactions to an implicit coalition of miners.

Tokens and AMMs

token

For reasons that aren’t entirely clear to me, humans love good tokens (or bad tokens, or tokens, really). Since the inception of Bitcoin, there has been talk about incorporating other tokens into the protocol, from colored coins and counterparties to the latest Taproot assets and runes. All of these protocols have one thing in common: This means that in order to determine the conversion of a token within the protocol, you need either knowledge of external data or an external index of Bitcoin transactions that processes the data in the Bitcoin transaction sequence. The important point of this article is that the Bitcoin lock script is completely unaware of the existence of the token, and even the Bitcoin nodes that verify transactions are unaware of the token (i.e. the Bitcoin lock script is not aware of the existence of the token at all). Even if you have full access to the entire Bitcoin UTXO set). , the status of these tokens cannot be retrieved).

Automated Market Maker (AMM)

In other blockchain systems, it is common to use a contract called AMM to fix the ratio between two tokens by buying or selling them at a fixed price. The rules that can be encoded in AMM are beyond the scope of this document. Suffice it to say that AMM creates enormous opportunities for MEVs and centralizes them due to the private exchange relationships needed to maximize returns for MEVs. This has often been used as an argument against building a more expressive Bitcoin script. We sincerely want to avoid exposing the Bitcoin network to an ambiguous situation where MEV is centralized. However, as described above, no matter how expressive the Bitcoin script is, there is no practical way to evaluate the state of a non-Bitcoin token. Bitcoin script cannot find rare sat. Rune balance not found. The Taproot asset cannot be identified.

Without access to information about the disposition of non-Bitcoin assets, the entire concept of a Bitcoin Script-based AMM no longer makes sense. Token positions can be proven with an oracle’s signature, but oracle proof does not create an AMM. Although it can be used to facilitate certain manual transactions, it is not a durable automated system. Moreover, these oracle-based systems can be built today without any changes to Bitcoin.

conclusion

As you can see, CAT is not such a scary beast. It’s not a beast at all. There is no infinite ability or magic power. It’s a small opcode that can be very helpful. One thing we probably want to avoid is enabling OP_CAT without another way to do transaction introspection, such as OP_TXHASH, OP_TX, or both. Enabling it using LNHANCE only improves OP_CAT because it reduces the size and complexity of the script needed to achieve the OP_CAT self-check protocol.

I think at this point "CAT Introduces Infinite Everything" ~Nothing has disappeared.

Here’s some useful self-reflection in a way that no one should ever use. If you don’t want people to use it, you’ll need to enable CAT along with TXHASH or similar. https://t.co/nvnxYn66Um https://t.co/1Ag5TwjuUw

— Reardon 🍯🦡 🦢 | Accept fork (@reardencode) May 17, 2024

This is a guest post by Brandon Black. The opinions expressed are solely personal and do not necessarily reflect the opinions of BTC Inc or Bitcoin Magazine.