Blogs & Articles: My Worries About Too Generalized Covenants 🔗 3 years ago

Covenants strictly speaking in Bitcoin land are just scripts or functionality that allows you to artificially restrict where a UTXO can be spent to. In general a covenant is defined as:

“a usually formal, solemn, and binding agreement : compact.”

These can be very useful for all kinds of stuff, adding extra security to cold storage vaults, enforcing the security model of second layers, etc. So before I get into the “what are the dangers” in my mind, lets look at some variants of covenants hopefully coming soon I don’t see any type of global danger in, just added utility.

ANYPREVOUT/eltoo

The very high level gain here is the ability to include an input in a transaction without referencing a specific UTXO by TXID and output index. When you include an input in a transaction, you have to point to the exact transaction that created it by transaction ID, and by it’s output index number in that transaction. ANYPREVOUT allows you to not do this. This lets you swap out that input with any other input that the signature would still match for (so same script, same amount).

Lightning uses this by pulling a neat trick. You construct a transaction (the trigger transaction) that funds an ANYPREVOUT output, and then you construct a second transaction (commitment transaction) that spends it, but just creates the same output over again (you are expected to pay fees with a new input). The idea here is that if the most recent transaction is what is pushed to chain, after a timelock window a third transaction (settlement transaction) can be pushed to chain to settle the channel balances. But what if someone pushes an old commitment transaction? Well with ANYPREVOUT, the most recent commitment transaction can spend the old one, and because of how eltoo structures things only a newer commitment transaction can spend an older one. So once you get the most recent commitment confirmed, everything is guaranteed to settle the correct amounts without penalties.

It can also be used to construct vaults that allow a transaction to be “clawed back” for a short duration after being spent using the same kind of replacement logic mentioned above for Lightning channels. This is a useful security mechanism for cold storage setups.

Lastly, you can create a long chain of pre-defined transactions that do nothing but re-create the same UTXO with ANYPREVOUT over and over again. This is very useful for committing to other data sets and guarantee only one commitment is made (because you can follow the single transaction chain and see what else other outputs commit to). Ruben Somsen’s Spacechains concept utilizes this scheme. I do want to note however that this is not useful in any kind of sense for general economic activity, as a pre-defined transaction chain doing nothing but recreating the same UTXO over and over again by itself is useless for that.

OP_CTV

OP_CHECKTEMPLATEVERIFY is a very interesting proposal. It allows you to make a proper covenant where at the consensus level the UTXO locked up with OP_CTV can only be spent to the place you define. Exactly the place you define. You can also chain things together, and create a UTXO locked with OP_CTV that creates more UTXOs locked with OP_CTV and so on. It does this by actually including the hash of the transaction you want to be the only way to spend a UTXO in the script of the UTXO itself.

This has numerous uses. Guaranteeing the withdrawal of thousands of customers by creating one UTXO, it’ll take a while to fan out on chain, but its locked in and can’t be stopped. Awesome option for custodial exchanges in high fee environments. It can be used to create a channel factory variant. Secure cold storage vaults. Even Lightning channels that don’t require interaction to receive money.

But again, I want to point out, this isn’t really useful for encumbering a coin forever that is intended to be used in general commerce. You can’t know all of your transactions ahead of time, so you can’t lock a coin intended to be freely used with OP_CTV. You can only know ahead of time so much, before you can’t, so inevitably chains of OP_CTV locked transactions must come to an end and create UTXOs not encumbered by OP_CTV.

The Danger

Neither of the above things can really pose a systemic risk for the Bitcoin system itself as a whole. They extend programmability and functionality that can be utilized to extend secondary layer protocols and improve security. They offer a way encumber coins more strictly than the global ruleset, but logically that stricter control must eventually reach an end point. However…covenants in general absolutely could pose global systemic threats if they were generalized enough. Both of the schemes above require knowing exactly where you want coins to go all the way to the end of the covenant, and then they are free again. What if I had a covenant that didn’t require knowing that?

Think about Blockstream AMP (Asset Management Platform). It’s a tool for the Liquid blockchain for asset issuers to issue their assets into 2 of 2 multisig wallets where they possess one key and the owner possesses the other. The point is for issuers to be able to comply with regulatory requirements for them to only allow certain people to hold the asset, to scrutinize transactions for legal problems before approving them, etc. The thing is though, this isn’t a consensus rule. It’s an application layer process. Those keys can be compromised, those regulations can change, those assets have the possibility of leaving that walled garden without changing global consensus.

But what if you could do something like that with a covenant? What if I could structure a Bitcoin script so that both the ostensible owner could spend it, but so could the government with their own key? What if that script also enforced that it’s UTXO could only ever be sent to a similar script without having to define the ostensible owners key ahead of time? The script doesn’t care what the owners key is, just that the government’s key is in the script and also capable of spending.

Those coins could never escape that system, by consensus, without a hardfork.

What if the script was locked to a key with a signature proving some identity authority has associated a real world identity to it and approved of it. What if the script locked those coins forever so they could only be sent to other such “identity approved” keys?

What if exchanges start depositing coins into such scripts? What if the institutions do? Once those coins are in there, the only way out is hardfork. Good bye fungibility, good bye.

Miners

51% attacks. I’m sure most reading are already thinking “who cares, Bitcoin is already broken at that point what are you talking about? Idiots who locked their coins into dumb covenants like that are on their own. Sorry, your problem.”

Well…no, a 51% attack doesn’t mean Bitcoin is broken. Unless some massive global coordination occurs all in concert, a 51% attack is a very expensive endeavor that can ultimately only do two things:

• censor transactions as long as they can afford to keep the attack going
• reorg a block to undo transactions

51% attacks don’t “break” Bitcoin unless they can be continued forever. They just disrupt it. But if you introduce the types of general covenants that could enable permanently restrictive scripts you could never escape like I mentioned above…well. What if you extorted users with your 51% attack to move into those? Those coins could never escape those covenants without a hardfork. A 51% attack is now a way to accomplish a global systemic attack on the coin supply that is permanent. It doesn’t just go away when the attack goes away, it sticks around forever unless you can accomplish a hard fork (good luck).

I think anything that enables permanent instead of transitory consequences to occur because of a 51% is foolish, and this is something that would allow bad actors to leverage such an attack to permanently bifurcate the coin supply and undermine fungibility and privacy.

So I guess my last thought? Never forget Chain Anchor. (If you haven’t heard of Chain Anchor, read that.)

My Worries About Too Generalized Covenants was originally published in Block Digest Mempool on Medium, where people are continuing the conversation by highlighting and responding to this story.