What’s all the covenant related drama on Bitcoin?

If you follow the bitcoin dev mailing list then you won’t have been able to escape the unfolding drama on CTV — a proposed update to add covenants to Bitcoin core. This was a panel I attended at Bitcoin 2022 and included one of the leading developers within the debate, Jeremy Rubin. Since then, there’s been a flurry of messages every day (literally flooding my inbox!!) with the various sides for and against covenants, for and against the various implementations, and most strongly (echoing the segwit implementation of 2017) around the potential activation methods.

Disclaimer: I have at least 100 unread bitcoin dev mailing list emails on this topic (honestly it’s impossible to keep up) and I’m in no way an expert on this. So if you’re following the drama and have addition updates or facts to add then please do share in the comments below! Also I’m pretty agnostic on the route going forward but have been leaning more towards delaying this until there’s more community consensus.

What are covenants?

A covenant is a set of conditions on a UTXO (Unspent Transaction[TX] Output — the ‘coins’ which are created, sent and destroyed on Bitcoin) which says how it can be spent.

There’s already some rudimentary covenants in Bitcoin such as locktime which allows you to set a rule on a UTXO that it can’t be spent before a certain UNIX timestamp or block height, and arguably P2SH (and taproot/segwit derivations thereof) address types allow conditions (also called scripts) to be set above and beyond the simply P2PKH address types which just require a signature from a certain private key. Multi-sigs are a simple example of this which require signatures from multiple private keys for funds to be spent — like a joint bank account. These existing implementations allow you to add conditions on what someone must do to unlock UTXOs.

However the idea with covenants, as being discussed now, is that these would be conditions on how/where you can spend the UTXOs after they have been unlocked

You might be thinking “but wait Tara, this sounds a bit like smart contracts and Bitcoin doesn’t have smart contracts, right?”

I’m glad you asked….

Actually Bitcoin does and it always has. However Bitcoin’s scripting language (the code that allows you to do ‘if then, then this’ type behaviours) is pretty rudimentary so you can’t do the impressive things like you can on Ethereum. So this upgrade would give Bitcoin some more exciting functionality to make more complex ‘if this, then this’ statements. It’s nowhere near the ability of Ethereum though!

What are the main covenant contenders?

The main contenders are:

- BIP119 with CheckTemplateVerify

(referred to as CTV) and as designed by Bitcoin Core developer Jeremy Rubin

The TL;DR is that this is intended to be the smallest unit of covenant implementation and so if you are pro-covenants then this allows an initial implementation of it without all the bells and whistles which might go wrong. In line with this, it’s only looking to introduce some limited smart contracting abilities, not everything possible. The smart contracting abilities would utilise Rubin’s own language, Sapio.

Notably, there’s been a significant amount of ad hominem attacks on this proposal rather than just focussing on feedback for the code or concept. Crypto twitter can be a very harsh place at times!

- BIP118 with AnyPrevOut

This was first proposed in 2017 as SIGHASH_NOINPUT to solve transaction malleability and with a Lightning Network focus, however since Taproot it’s come back around as a potential Bitcoin core proposal.

The TL;DR is that it will allow a transaction with this type of sighash flag not to be linked to past transactions and therefore it can spend any bitcoin from addresses with the same public key (or conditions for spending).

The main benefit of this are:

• Lightning: With Eltoo [pronounced like L2] where you can keep only the state of the last two channel transactions (rather than everything) — one of these last 2 transactions must be an ANYPREVOUT, and then if there’s any disputes about balance, you can use this ANYPREVOUT to send the funds back to you. This therefore reduces scaling concerns as the LN grows. In addition this would introduce the possibility for blind sidechains on Lightning (basically a solution which doesn’t require 3rd parties)
• Allowing more complex scripting conditions, hence why this proposal is part of the covenant debate.

There are a bunch of other ideas but they’re not at BIP (Bitcoin Improvement Proposal — official suggestions for code updates to the network) stage yet so these are the main choices. However Taro (the recent Lightning announcement for a new UTXO tree allowing for assets on Lightning) is a mini-implementation of this but doesn’t allow for Vaults and other features as will be noted below, so isn’t the full implementation that people who want covenants would want.

Why do people want or not want covenants?

The main pro’s for covenants are:

• You could use these for channel factories for Lightning so you can open/close/edit many channels in one transaction rather than requiring one UTXO per channel modification. This bring fee and scalability benefits.
• Vaults — this is another big upgrade many people want. It’s essentially a self custody solution at the protocol level (It’s a super cool idea in my humble opinion!) and would add extra protections after your bitcoins have been hacked or for more complex treasury management of your coins generally.
• It could also allow for congestion controlled batch transactions where you can compress transactions into a single transaction and then once the mempool in less congested, you can expand it back out and process each one
• It provides a more rich design field for other use cases at the protocol level rather than having to do some of this scalability/security protections using 3rd parties and off chain
• This would be opt in and backwards compatible
• But basically this just levels up the Bitcoin feature set and opens up a whole new bunch of use cases — many of which are unknown right now

The main negatives for covenants are:

• Some say they’re overly complex and so won’t be used by the everyday Bitcoiner and hence aren’t something to focus on now
• Some say they could be an attack on fungibility
• Some say this overcomplicates Bitcoin generally and proponents of upgrades like this should stop trying to make Bitcoin like Ethereum
• Some say they could be used to add censorship/blacklisting and gov/law enforcement could pressure on/off ramps to add their signoff as a covenant. [However this fails to acknowledge they could try to do this with a multisig at the moment so this wouldn’t be a new covenant-only attack vector and isn’t (to my knowledge) something we’ve seen in practice.]
• Some people are worried about recursive covenants because they could be a new attack vector (e.g getting into a covenant that you can’t get out of)
• There’s also the risk that if people don’t understand the covenant on the coins, then they might sign up to something they don’t understand/is a secret attack. (Although Rubin has stressed we would need more tooling on analysing ability on covenants [like we have auditing on Ethereum smart contracts] to help protect against this and arguably this is already a risk with smart contracts today)
• Some argue that Jeremy is trying to push this through too quickly and regardless of what it is, there needs to be a more robust peer review and consultation process. Jeremy’s response is that they should ship it and iterate. Although that’s generally not a very Bitcoin approach to protocol changes! Likewise some argue that a minority requested/liked change shouldn’t be coming through at a protocol level and ‘wasting’ Bitcoin core’s time.
• Also some say that we’ve only just had Taproot out and we should focus on rolling that out and making the most of the benefits and opportunities rather than bringing something new

So it’s clear to see there’s strong arguments and opinions on both sides!

How might we get covenants?

However this isn’t just a debate about which covenant proposal to implement or if we should even have covenants at all, there’s also a fierce debate about any potential activation methods.

Unlike a hard fork, which is where there will be a new version of the Bitcoin core code which everyone has to update to in order to stay on the main chain and not fork off, this would be a soft fork change e.g backwards compatible, so doesn’t require client or wallet upgrades. Therefore anyone using Bitcoin before can continue to do so after this change with no disruption, they just can’t take advantage of any of the upgrade benefits. However there’s a few ways to roll a soft fork out.

It’s worth noting that much of this is hitting on a sore spot from back in 2017 with the segwit upgrade (another soft fork) where there was a HUGE debate about activation method and many people are still very unhappy about what went on (although there’s a bunch of fud and fake news in the space around this too). I’d suggest reading this for a good overview of the drama: http://r6.ca/blog/20210615T191422Z.html.

The TL;DR is that the change itself was uncontroversial (after a few camps forked off) but there was disagreement over who should activate the change; miners, users, exchanges etc . Because whoever pressed the big red button had the ‘control’ / ‘privilege’ etc.

So how do people want to implement covenants?

Terminology time …

• BIP9: Used in the segwit activation where miners signal, using the version field in the block header, if they are ready to support the change or not. Then once a pre-set % of blocks are showing support within a pre-specified window, then the change is locked in and activated a few blocks later.
• BIP8 (also referred to as a flag-day activation): where a specific block height is set and when that’s reached the upgrade is activated.
• Speedy Trial: This could be used with BIP8 or BIP9 and is where parameters are set to activate the upgrade or if the threshold is not met then it expires and a new activation plan must be formed. For the Taproot upgrade, this was achieved with Speedy Trial of BIP9 with a 3 month signalling window of network hashrate and then activation a few months later. However it’s worth noting that some Bitcoin core devs vehemently hate BIP9 implementations of speedy trail (like Luke Dashjr!)
• User Activated Soft Fork (UASF): Where those running nodes; exchanges, wallets, blockchain analytics companies etc, set up them up to only broadcast/receive blocks which support the upgrade.
• User Resisted Soft Fork (URSF): A proposal from Michael Folkson specifically for the CTV debate to avoid a situation where the majority (or even 90%) of miners are running v23 Bitcoin Core or another out the box implementation (which doesn’t include any CTV code or signalling against it) but the wider community disagrees with it. Notably, Jeremy Rubin wrote some code for this so anyone who disagreed with his proposal could easily implement it.
• Miner Activated Soft Fork (MASF): Where miners just upgrade on their own timelines and start rejecting blocks from other miners which don’t support the upgrade

The planned implementation for CTV (until very recently!) was Speedy trial with signalling starting from May 12th (initially it was May 5th) until August 12th and an activation time of cNov 9th at block height 762,048. Jeremy even set up a website to start monitoring signalling for individuals, companies and miner: https://utxos.org/signals/.

However …. because of all the drama, Jeremy shelved this and did not release the code for a Speedy Trial of CTV nor his plans for a UASF on the upgrade. A notable quote from a Bitcoin Core mailing post he made a day ago is:

The hate may be loud and public on the shallow surface, but the love and support runs deep.

So does this mean covenants are scraped? Nope! There’s now a few threads on the mailing list about whether ANYPREVOUT (or the slightly new implementation of ANYONECANPAY) should replace the CTV implementation! Plus there’s still plenty of debate about how soft forks should be activated in the future (focussing on the triumvirate of who’s in control: nodes, miners or devs).

Why is all this important?

“While I would expect nothing less than passionate debate when it comes to Bitcoin, remember that at the end of the day we all largely share a mission to make the world a freer place, even if we disagree about how we get there.”

Jeremy Rubin to Bitcoin dev Mailing List 02/05/22

If CTV comes back around or things move forward with OP_APO/OP_AOCP, then this could pave the way for a whole bunch of new functionality and use cases on Bitcoin. This opens up new opportunities for Bitcoin developers and any businesses who interact and develop on Bitcoin.

This drama is also a useful view into the often turbulent world of decentralised protocol development where no-one is in control and consensus must be reached. This isn’t the first controversial upgrade suggestion and it certainly won’t be the last, but it’s fascinating to see how the developer community is growing, evolving and trying to set precedents for how to upgrade the world’s most important cryptocurrency.

One to keep a watch on for sure ….

Originally published at https://www.linkedin.com.