I wanted to write this blogpost as a way to better understand OP_CAT. I knew that
OP_CAT as a primitive was powerful based on existing literature, but it was unclear how it was
fitting into the full picture
of bridges being built on top of it, vaults, snark verifiers, drivechains and more! The opposition of the
proposal usually make MEV out to be the reason so I also wanted to look a bit into that.
OP_CAT with Taproot v1.
OP_CAT. The maintainer of that, sCrypt, also has an OP_CAT series.
The following quote basically summarizes the core idea behind the transaction introspection with
OP_CAT.
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 validation with CAT.
There is a more technical blogpost written on this by Andrew Poelstra:
So let's quickly go over the results of that blogpost. Some things that need to be known: all of this is related to Schnorr signatures, which were introduced into Bitcoin through BIP 340.
The signing equation of Schnorr is $s = k + xe$ where $k$ is the secret nonce, $x$ is the private key, $e$ is the $\text{hash(P, R, tx_data)}$, $R$ is the ephemeral key and $P$ is the public key. Users can grind some of these fields to get a collision which is the core trick. If we make $x = 1$ and $k = 1$ then $s = 1 + e$.
So $s$ is essentially now just the transaction hash + 1. Dealing with the + 1 within script is a bit annoying as Bitcoin script doesn't allow subtraction on it, but we could circumvent it by just doing some grinding to make the transaction hash have a predictable last byte. The locktime and sequence number are examples of values the user can grind.
If we provide the ephemeral key and the signature on the stack, we can use the following Bitcoin script that
Andrew Poelstra shared
2DUP CAT ROT DUP <G> EQUALVERIFY CHECKSIG to get out
$s$ which would be the $\text{hash(P, R, tx_data)}$. The script would then also need to reconstruct the
hash
to verify against it and that is very much possible in Bitcoin script.
Note that Robin Linus did find a similar trick with ECDSA: Further Details
If you read the previous section you know that we have a way to get transaction introspection which would also allow us to control the spending of the coins. This includes spending amount, number of inputs, number of outputs, who spends the coins, and more.
This builds on the same idea as the normal covenants. If we enforce through script that the first output must have the same locking script and that the second output must contain the next state, we could have more stateful computation.
This idea is explored more in the following places:
One of the most fundamental data structures in cryptography is not possible in Bitcoin today, or technically they are possible, but would not be optimal at all. The reason is that since you can't concat to create the next leaf node, you would need to implement the hash function directly from within script so that you can control the way the internal hash function state is transitioned.
Once you have OP_CAT creating merkle trees becomes trivial as you can use the hash functions
provided by script and concat data to create the leaf nodes.
Since STARKs mostly consist of hashing and concatenation one can now also get STARK verifiers on top of
Bitcoin thanks to OP_CAT. This is also
mentioned by Starkware.
This is explored in more detail here:
Building on the ideas we have covered above, it might not be surprising that OP_CAT also allows
us to build better bridges. The idea would be to use merkle trees for handling the storing of the accounting
of the bridge. Although the actual implementation and productization of this is a bit more complex. Implementing a Bridge Covenant on
OP_CAT-Enabled Bitcoin: A Proof of Concept explores this more.
OP_CAT allows implementation of DriveChains using covenants tricks and
M-N multisig to allow (selected) miners to vote on the hashrate escrow.
Miner Extractable Value are additional profits that miners can make by prioritizing or reordering transactions. This creates centralization pressures as the transaction fee is no longer the core metric for miners to mine based on. The miners are then required to invest in better analytical tools to earn more money.
Blockstream wrote a more general article about MEV that has some core ideas for how to think about MEV on Bitcoin. That covers the three factors that contribute to MEV consisting of mempool transparency, contract transparency and contract expressivity. Compared to other more expressive smart contract blockchains like Ethereum which has private mempools and complex smart contracts like DEXes which allows side-effects like sandwich attacks. Properties that are not ideal for Bitcoin.
Eric Wall explores some of this in the context of OP_CAT. The focus of this blogpost is the
complexity of block building which can happen as a result of OP_CAT. Any second layer or meta
protocol can introduce new meaning to transactions that happen on the baselayer. Ordinals have already shown
and proved that this is the case. There are properties of Bitcoin which make the baselayer more robust to
certain kinds of MEV, one of them being the ten minute blocktime and second the expressivity of scripts.
However with OP_CAT there will be new layer-2s built on top of Bitcoin and the question then
becomes if there is a L2 full of MEV, would that also affect the baselayer? Looking at Ethereum today, the
MEV does not leak back to the L1.
There has also recently been a lot of debate around this because of the The MEVil of Relay Policy and the ongoing filtering wars. There also exists MEVPool for Bitcoin which is very similar to the builder/proposer separation on Ethereum. Although this seems to have less eyeballs in the current landscape.
It's clear that OP_CAT although a small code change of just nine lines of code, is a very
powerful primitive to have. Companies like Flashbots and Starknet (with friends) have already shown
interests in looking into the second order effects of enabling this opcode.