Does bitcoin need covenants?

Does bitcoin need to change?

Who am I?

Long time bitcoiner and coder

Occasional BIP contributor

Former

MuSig2 fanboy

Contents

• What are covenants?
• Does bitcoin need covenants?
• Possible covenant features
• Plain english (hopefully) descriptions of several covenant proposals
• Opinions
• Questions

What is a covenant?

From Dictionary.com:� Covenant, n: a usually formal, solemn, and binding agreement

From Investopedia:� Covenants can either promote activity to occur (positive covenant) or disallow an event or condition (negative covenant).

For bitcoin:� Covenants restrict the context in which bitcoin is spent by reference to data outside of its locking and unlocking scripts. This contrasts with cryptographic signature verifications which restrict who can spend bitcoin.

Does bitcoin need covenants?

Bitcoin already has covenants.

OP_CHECKSEQUENCEVERIFY and OP_CHECKLOCKTIMEVERIFY are covenants.

These covenants enabled the lightning network� and other improvements for bitcoin users.

Does bitcoin need more covenants?

Covenants scale bitcoin.

Covenants enable holders to protect their bitcoin from theft or loss.

Covenants enable holders to share UTXOs and on chain transactions.

Doesn’t lightning scale bitcoin?

Yes (thanks to covenants), but only to ~100 million users with 1 channel each.

If bitcoin is going to serve the world’s financial needs, it needs more covenants.

Bitcoin needs more covenants.

But covenants are scary!

Let’s talk about it.

How are covenants applied?

To receive bitcoin you create an address and provide it to the sender.

Most addresses lock bitcoin until a signature matching a public key is provided. Roughly, this corresponds to a locking script script like:�<public_key> OP_CHECKSIG

You can apply a time lock covenant by providing an address for a script like:�<public_key> OP_CHECKSIGVERIFY <time> OP_CHECKLOCKTIMEVERIFY

Only you can apply a covenant to your address.

Only you can apply a

covenant

to your address.

What are they good for?

Possible covenant features

• Specify the exact next transaction
• Require a series of transactions to send bitcoin to an outside address
• Allow bitcoin to be recovered to a “safe location” during such a series
• Limit how much is spent in the next transaction
• Whitelist addresses
• Control how bitcoin can be spent with other bitcoin
• Many, many more…

Let’s get specific.

Types of covenant

• Transaction hash�Some hashed transaction data available to script
• Transaction introspection�Some transaction data available to script
• Script transformation (specialized introspection)�Require a modified version of the input locking script in an output
• Deferred (specialized introspection)�Require some invariant to hold across multiple input locking scripts

More specific?

OP_CHECKTEMPLATEVERIFY (BIP-119)

• One new opcode
• Restricts the exact next transaction (except the inputs)
• Enables Ark and similar UTXO sharing proposals
• Improves DLCs, lightning, and many more
• Similar scope to OP_CHECKSEQUENCEVERIFY and OP_CHECKLOCKTIMEVERIFY
• Added to the bips repository in February 2020
• Pull request to add it to bitcoin core first opened in April 2021

Hash

SIGHASH_ANYPREVOUT(/ANYSCRIPT) (BIP-118)

• Two new tapscript key types (33-byte and 1-byte beginning with 1)
• Allows signatures for these new key types not to cover inputs
• Enables Lightning Symmetry (Eltoo) and PTLCs
• As a covenant: similar to OP_CHECKTEMPLATEVERIFY, but not restrictive enough to predict TXIDs and inefficient (uses pre-signed locking scripts)
• Approximately twice as much scope as OP_CHECKTEMPLATEVERIFY
• Added to the bips repository in May 2018 (as SIGHASH_NOINPUT)
• Pull request for bitcoin core in Sept. 2023 in the Covenant Tools softfork

Hash

OP_UNVAULT/OP_VAULTRECOVER (BIP-345)

• Two new opcodes
• Uses OP_CHECKTEMPLATEVERIFY
• OP_UNVAULT creates a series of delayed transactions to send bitcoin
• OP_VAULTRECOVER allows bitcoin to be recovered to a “safe location”
• Similar scope to SIGHASH_ANYPREVOUT
• Added to the bips repository in March 2023
• Pull request for bitcoin core in Sept. 2023 in the Covenant Tools softfork

Deferred,

Transformation

OP_TXHASH(VERIFY)

• OP_TXHASHVERIFY provides OP_CHECKTEMPLATEVERIFY features and more
• OP_TXHASH with OP_CHECKSIGFROMSTACK provide SIGHASH_ANYPREVOUT(/ANYSCRIPT) features and more
• Common hashing for equality and signature verification
• Greater scope than others
• First proposed in January 2022
• BIP first published in September 2023
• Reference implementation published in October 2023

Hash

Template Key

• Enhancement to OP_CHECKTEMPLATEVERIFY (rules for 33-byte arguments)
• Alternative to SIGHASH_ANYPREVOUT for the same new tapscript keys
• Common hashing for equality and signature verification
• This one’s mine
• Greater scope than others (except OP_TXHASH(VERIFY))
• Derived from TXHASH email and limited OP_TXHASH proposal from Aug. 2023
• BIP first published in September 2023

Hash

OP_CAT

• Originally included in bitcoin script
• Can emulate OP_CHECKSIGFROMSTACK thanks to math
• Can emulate other covenants (for transactions < 520 non-witness-bytes)
• Very small in scope
• Discussed since the beginning of bitcoin
• BIP published in October 2023

Hash+Introspection

Proposal Relationships

CHECKTEMPLATEVERIFY

Template Key

UNVAULT

TXHASH(VERIFY)

Replaces / Upgrades

Upgrades

CHECKSIGFROMSTACK

Emulates

SIGHASH_ANYPREVOUT(/ANYSCRIPT)

VAULTRECOVER

OP_CAT

Recursive

Replaces

Emulates

Uses

Opinions

Bitcoin needs to change!

OP_CHECKTEMPLATEVERIFY (BIP-119) belongs in bitcoin.

SIGHASH_ANYPREVOUT(/ANYSCRIPT) (BIP-118) is uninspiring and harmless.

OP_UNVAULT and OP_VAULTRECOVER (BIP-345) probably belongs in bitcoin.

OP_TXHASH(VERIFY) might belong in bitcoin.

Template Key might belong in bitcoin.

OP_CAT might belong (back) in bitcoin.

OP_CHECKTEMPLATEVERIFY

(BIP-119)�belongs in bitcoin.

Questions?

@reardencode (𝕏 and elsewhere)

freedom@reardencode.com