You may not have noticed, but while everyone has been arguing about OP_CAT and other covenant soft fork proposals over the past year, several teams have figured out how to do covenants on Bitcoin without needing a soft fork at all.
That’s right – researchers have discovered three different ways to create covenants without needing a soft fork. But each comes with a tradeoff to cost, trust assumptions, or security.
Let’s take a look at these different ideas with as little technical jargon as possible.
What are covenants?
A covenant is a pre-specified transaction condition that restricts future Bitcoin spending. For normal users, this might involve dramatically improving self-custody with backup addresses or making the lightning network much easier to use. Covenants can do many things, and we’ve written plenty on them before.
While most devs and users see use-cases for certain covenants, they weren’t previously possible on Bitcoin without a soft fork for an opcode like OP_CAT, OP_CHECKTEMPLATEVERIFY (CTV), or OP_CHECKSIGFROMSTACK (CSFS). However, following the past year of discussion and renewed researcher interest in Bitcoin, several teams have come up with ways to emulate covenants without a soft fork.
Covenants using cryptography
We can use cryptography to essentially store data on Bitcoin that, when decrypted, creates transactions that a user could only produce with a covenant. If you have the key or “cipher,” you can use that to decrypt transaction signatures. That scheme would give you transactions which mimic a covenant. Bitcoin PIPEs and “FE’d up Covenants” are versions of these cryptographic tricks.
However, all of these cryptographic schemes are just theoretical designs, we have yet to see an actual implementation on-chain as far as we know (although we do expect one to happen soon). If you want to know more about Bitcoin PIPEs we have a whole Bitcoin Season 2 podcast about them!
Hash collision covenants
If you’ve got enough money and computers, you can kind of brute force a covenant onto Bitcoin.
Recently, a team of independent researchers alongside Starkware and Blockstream published a method to use “hash collisions” to simulate OP_CAT in Bitcoin script. For the layperson: when we find large numbers that conflict with each other, we can kind of trick a Bitcoin transaction into interpreting the script in a way that produces a covenant.
TL;DR: we use a bunch of computers to generate a bunch of numbers to produce a certain specialized Bitcoin transaction in a process similar to Bitcoin’s proof-of-work mining.
We know we can do this today, it would just cost a lot of money to produce. Initial estimates put the number in the several million dollar range to produce a single covenant because of the cost to run the computers. That may sound crazy expensive, but consider that a company like Starkware (who wants these types of covenants) spends tens of millions per month on Ethereum for their L2 starknet, so only spending a few million per month may not be prohibitively expensive.
Covenants with an oracle + BitVM
Just this week Jeremy Rubin published another scheme that emulates covenants on Bitcoin. A third party oracle cosigns transactions – but only transactions that follow the specified covenant. If the oracle signs a transaction that violates the covenant, a BitVM challenger can punish it. So, an oracle puts up collateral (a bond) that it forfeits should it misbehave.
Jeremy says that this scheme would technically be very cheap to do once the oracle is bonded. Basically, very cheap to do, but it requires a trusted counterparty. So even though you can penalize the counterparty if it misbehaves, there’s still a tradeoff.
So why do we need a soft fork if we can already do these things?
In my own view, this means the concerns about what a soft fork might lead to are much less valid, because they are going to happen anyway.
“Unknown unknowns” are a moot point because they are not really preventable, so we might as well make the covenants more practical. It is vastly more efficient to have dedicated opcodeswhich means fewer people are priced out of using Bitcoin L1 or priced out of covenants in general. On the other hand, some might argue that “we don’t need covenant soft forks because now we already have them.” But that would still render the majority pushback against covenants, the fear of unknowns, mostly a non-issue.
Additionally, the more expensive and complex the scheme, the bigger the hurdle the average bitcoin user has to clear to take advantage of them. To this point, Ethan Heilman presented a rough chart describing the range of costs it would take to produce/emulate covenants for each scheme.
Where does this go from here? If we were to speculate, we think that we will get covenants on Bitcoin in 2025 one way or another.
