Introduction
You may have heard about re-enabling OP_CAT as a potential upgrade to Bitcoin’s scripting language. Depending on where you get your news, OP_CAT has been described as “just 10 lines of code,” “the best way to enable Covenant experimentation,” “too powerful,” “dangerous and centralizing miners,” or “surely It is said that this will lead to the centralization of miners. A controversial soft fork.” I would argue that all of these views are wrong. OP_CAT is very useful and can be used as a contract, but it is not (alone) the best next move for Bitcoin. Nothing more, nothing less.
To make that case, I’m going to explore a few (seemingly disparate) topics, some of which were new to me a few months ago. I’ll try to organize this to give you the background you need in one place.
OP_CAT features and methods
Introspection with CAT
Let’s tackle the burning question that many people have when they first encounter OP_CAT. Combining two items from the stack into one (AB CAT -> AB) How can you do something interesting with just a few lines of code? As Andrew Poelstra eloquently puts it: is explained. Recent interviewand I posted a ridiculously simple explanation:
Bitcoin is a little different, so you can also split things up. Then you can use SHA256 to unhash it. CAT allows us to extract a hash from a signature verification because cryptography is just math and we know how to calculate it. As a result, anything hashed in the signature can be inspected…
— Rearden 🍯🦡 🦢 | Accept fork (@reardencode) May 17, 2024
Bitcoin Script is strictly a verification language, so each opcode can be used in forward or backward directions. The script can either be given a hash and ask for a preimage, or given a preimage and ask for a hash using OP_SHA256. This insight gives us the first two parts of how the OP_CAT covenant works.
If a Bitcoin script has access to the hash of the transaction it is validating, it is necessary for the spending stack to provide a hash preimage, split it up in any way the script needs, and then validate specific parts of that preimage. It may become. This is exactly what a covenant means: validating some of the transactions that consume Bitcoin.
That’s great, but Bitcoin doesn’t have an opcode like this: OP_TXHASH Allows the script to access the transaction hash. here, BIP340 Schnorr A signature verification expression that requires the user to provide a hash. If the user specifies a value that is a valid transaction hash if the script concatenates byte 0x00 to the end of it, the script appends byte 0x01 to it.
Combining these techniques allows OP_CAT to check every part of a spend transaction that can be signed and even look back on the parent transaction in a limited way. With careful code, you can build it like this: complete storage, CatVMmore.
Other uses of CAT
But you shouldn’t. Building these things with OP_CAT results in ugly things that are difficult to maintain. Instead, it should be used to take advantage of OP_CAT’s strengths. And there are many such advantages. OP_CHECKSEPARATESIGCheck Merkle inclusion proof and combine with data for signature verification OP_CHECKSIGFROMSTACKmore.
CAT Problems
Now that we know what CAT does, what’s the problem? Why do people (including myself) say it’s a dangerous beast? CAT uses the above introspection techniques to enable her two specific constructions: hashrate escrow and (possibly) automated market maker (AMM). Until recently, both of these were considered significant risks of centralizing MEV to Bitcoin.
Unification of MEV, MEVil, and miners
The term MEV (Miner Extractable Value) is a bit confusing. In the simplest interpretation, this would include transaction fees, which of course we want to pay miners to ensure the safety of Bitcoin into the future. MEV is typically used to mean the additional value that miners can extract from a block above and beyond the price shown on public relay networks. This is due to out-of-band payments, miners joining contracts and reordering transactions in a way that favors them, and even miners rearranging and doubling up confirmed payments to sellers. It can take the form of outright theft of goods or services. All of these forms of his MEV are generally bad for network participants, as miners are exploiting their position in the network for their own benefit at the expense of other network participants. It is considered. However, MEV alone does not create systemic problems by promoting miner centralization, it only creates local problems, especially for affected participants.
MEVil is a term sometimes used for MEVs that promote centralization of miners. I prefer and will continue to use the term MEV centralization. To convert a MEV to a centralized MEV, several things are required.
- It needs to be extremely difficult to extract so that an open source block template builder can’t reasonably extract it.
- The total extractable value should increase with the miners’ Bitcoin hash rate
- The value that can be extracted must be worth the cost of extraction
If all these requirements are met, only miners of sufficient scale will have an incentive to start extracting MEV. This would allow the company to outpace the growth of its smaller peers by generating additional revenue. The more expensive it is to extract MEV (the less it is valuable to miners), the worse the centralization pressures it creates.
Avoiding MEV centralization is (sort of) easy. Every MEV opportunity that exists in Bitcoin is either so easy to extract that everyone does it, or it costs more to extract than it’s worth (either because it’s so small or so expensive) .
Learn more about @a_o_o_o_o_‘s recent posts.
Hashrate Escrow (nee Drive Chain)
Years ago (before ideas like Lightning Network, Ark, Timeout Trees, Rollups, BitVM, CatVM, etc.), sidechains were considered the ultimate scaling solution for Bitcoin. The idea was conceptually simple. For normal decentralization reasons, the size of a Bitcoin block must remain limited, but by connecting sidechains to Bitcoin you can get faster blocks, bigger blocks, more computation, etc. You can do. However, implementing sidechains was not so easy in practice. Final settlement in Bitcoin is fundamentally tied to proof of work, the irrefutable cost of reordering a transaction, but how do sidechains inherit that? How can Bitcoin be sent to and from a sidechain? The most popular proposal to answer these two questions is called Drivechain (BIP). 300 and 301). I won’t go into the details of the drive chain, but there are only two outcomes of such a side chain system. Either the drive chain is relatively unused (and therefore useless), or it becomes widely used and becomes the de facto block size. Increase in Bitcoin. This kind of de facto block size increase is a form of centralization in MEV, where only large miners can afford the additional revenue opportunities provided by potentially large and complex sidechain blocks. You will be able to participate more efficiently.
One small part of the Drivechain proposal is the hashrate escrow that can be built using OP_CAT. It is a system that limits withdrawals from the sidechain using a counter whose value can only be changed by miners, which starts high and must reach zero before the sidechain withdrawal can be processed. While this is claimed to be a “trustless” transfer from the sidechain, in reality it creates a coalition of miners that controls all Bitcoin held on the sidechain.
Since the development of the DriveChain proposal, it has become common (to our detriment) to refer to any proposal that can be used to make withdrawals subject to miner-controlled counters as a “DriveChain”. Hopefully it is clear at this point why this inappropriate shorthand is useless. DriveChain is either worthless or dangerous, while hashrate escrow is just a way to transfer control of the outcome of some transactions to an implicit coalition of miners.
Tokens and AMM
token
For reasons that are not at all clear to me, humans like good tokens (or bad tokens, or just tokens). Almost from the beginning of Bitcoin, there has been discussion about how to embed other tokens into the protocol. color coin and trading partnerto more recent ones Taproot assets and runeAll of these protocols have in common that they require an external index of Bitcoin transactions, either with knowledge of external data or processing data from a set of Bitcoin transactions, to determine the conversion of tokens within the protocol. The key takeaway for this article is that the Bitcoin Lock script has no knowledge of the existence of the tokens at all, and even the Bitcoin nodes that validate transactions are not aware of them (i.e. even if the Bitcoin Lock script had full access to the complete Bitcoin UTXO set, it could not discover the state of these tokens).
Automated Market Maker (AMM)
In other blockchain systems, it is common for contracts known as AMMs to be used to fix the ratio between two tokens by (for example) 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 a huge opportunity for MEV, and because they centralize the private exchange relationships necessary to maximize the returns on that MEV, they also centralize MEV. This is often used as an argument against building a more expressive Bitcoin script. We sincerely want to avoid exposing the Bitcoin network to the vagaries of MEV centralization. However, as we explained above, no matter how expressive the Bitcoin script is, it has no practical way to assess the state of tokens other than Bitcoin. Bitcoin scripts cannot find rare sats. They cannot find Rune balances. They cannot identify Taproot assets.
Without access to information regarding the disposition of non-Bitcoin assets, the entire concept of a Bitcoin script-based AMM becomes moot. The location of the token can be proven by a signature from the oracle, but the oracle’s proof will not create an AMM. They can be used to facilitate certain manual transactions, but cannot be used as durable automated systems. Moreover, such oracle-based systems can be built today without any changes to Bitcoin.
conclusion
As you can see, CAT is not that scary of a monster. Actually, it’s not that scary of a monster. There are no infinite abilities or magical powers. It’s just a very useful little opcode. What you probably want to avoid is activating OP_CAT without using another method of performing transaction introspection, such as OP_TXHASH, OP_TX, or both. Enabling it on LNHANCE alone is an improvement over OP_CAT alone, as it reduces the size and complexity of the scripts required to implement many OP_CAT introspection protocols.
At this point, I think “CAT Introduces Infinite Everything” ~ Nothing is left.
It offers useful introspection in a shitty way that no one should ever use. You should enable his CAT along with TXHASH etc. to prevent people from using it.https://t.co/nvnxYn66Um https://t.co/1Ag5TwjuUw
— Rearden 🍯🦡 🦢 | Accept fork (@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 his BTC Inc or Bitcoin Magazine.
