Shinobi’s Strawman is a weekly series where our Technical Editor Shinobi challenges the Bitcoin community, aiming to stir up conversation around heated technical debates.
______________________________________________________________
It’s been two years since the last upgrade to Bitcoin, Taproot, activated and went live on the network. Since then there has been a proliferation of proposed changes for the next upgrade to the protocol, and they seem to keep piling up faster than people can keep up with.
These proposals mostly fall into a single category of change: covenants. The basic purpose of a covenant is to fundamentally change how script restricts Bitcoin spending. Currently a script in a UTXO can only control or limit how that currently existing UTXO can be spent, the design goal of a covenant is to extend that restriction so that the script in the currently existing UTXO can restrict how future UTXOs not yet created can be spent.
I myself have voiced concerns in the past about the risks of enabling covenants, but came to the conclusion (touched on here) that those initial concerns were way overblown. I still think there are negative consequences that could potentially come from covenants that enable too many restrictions on future UTXOs, but those concerns are mostly rooted in potential incentive changes, not the abuse of covenants themselves to censor people.
Here’s the kicker though: we absolutely need some form of covenants for the scaling direction we have gone in to really work in the long term. Systems like Lightning are all built around pre-signed transactions being used to restrict the spending conditions of future UTXOs, but this can be very limiting.
Changing the state of a Lightning channel with just two people in it is straight-forward and just requires a few transactions being signed. The balance change, any new HTLCs or contracts, and a few transactions to handle those. However, the number of transactions you need to sign starts growing for the more complicated the thing you are trying to do is. I.e. involve more than two people in a channel. Think about penalties, right now one person just penalizes the other person, it’s very simple. The cheating party loses all their money to the single party being cheated.
How does that work with three people in a channel? It’s no longer a matter of everything going to one person, the right amount has to go to every other person being cheated. And that right amount changes each time the channel updates. So every time the channel state changes, you have to sign (or create in some way) transactions that will penalize every single old channel state while ensuring the money goes to the other participants correctly matching the current state balances. And you somehow have to make sure that only the most recent penalty can be used, otherwise old ones made with different channel states won’t distribute the money properly after someone tries to cheat. Imagine having to sign all of that growing set of transactions everytime you update a channel, it’s totally unscalable (if you could even find a way to make it logically work in the first place). SIGHASH_ANYPREVOUT (APO) enables a solution to this through eltoo, allowing people to simply replace old states with the current one instead of penalizing people.
Similar issues occur when you consider trying to handle on-chain enforcement of things. If you pack 10 people into a single channel, what happens when one doesn’t respond? You have to close the entire thing out on-chain and stop everyone from continuing to update things off-chain. Proposals like OP_TAPLEAFUPDATEVERIFY (TLUV) and OP_EVICT would offer a way for a single user to exit from a channel non-cooperatively without closing it for everyone else, or for everyone except one unresponsive person to eject that offline party efficiently and keep the channel open for themselves.
Long chains of pre-signed transactions can commit to individual payments occurring, channels being opened, etc. ahead of time. In order to be trusted though, that chain of transactions has to start from a multisig address where you are a keyholder, otherwise whatever is being committed to can be double-spent and voided. This necessitates a long set up phase of creating the multisig, everyone having to be online to sign everything, and then finally funding it. OP_CHECKTEMPLATEVERIFY (CTV) allows that to be done trustlessly without having to participate in a long complicated setup phase.
Everywhere we look and find problems or points of friction in making Lightning and other off-chain protocols work, some basic covenant proposal can elegantly address the problems. There are plenty of them too:
I would not be shocked if I’m missing some either. Some of these proposals, or derivatives, or new ones not net thought of are going to be necessary in order to continue scaling Bitcoin. There is no way around that, either we accept the limitations of Bitcoin as it is now, or we improve it to address those limitations.
So, we’re going to do the same thing as the last Strawman. What are your thoughts on covenants? Do you have specific proposals you think are most interesting or useful? Any thoughts on what could be built, or what problems can be solved, using them? Are there things you don’t understand about them? How they work, what they are useful for, what the risks and downsides are? Let’s hear it.
DMs are open, and opinion@bitcoinmagazine.com is available if that works better as a submission method. Next Wednesday we’ll do the same thing as last time and I’ll go through and publish the responses with answers to any questions or thoughts on the replies.
