heilman-covenant-rationale.md

Rationale

Ethan Heilman's rationale for the current covenant proposals document on the Bitcoin wiki. This is likely to change over time.

My rationale is guided by the following principles:

• I am not evaluating based on what I rate the consensus to be, but on what I think we should activate.
• In cases where two proposals have roughly the same functionality, I do not pit them against each other. I ask, would I be conformable activating either one.

Currently my rationale focuses most heavily on CAT, as I am most familar with CAT. This is likely to change as I continue to update this document.

Change list

• Dec 12, 2024 - Created file and posted initial rationale

Rankings

Preference	What I mean by this preference
Prefer	I support immediate activation
Weak	Better than nothing at all (not actively supporting it, but not opposing it)
No	I oppose activation
Evaluating	I don't understand the proposal well enough for my opinion to matter

Proposals

OP_CTV

Prefer:

• CTV has immediate utility for layer-two protocols by removing interactivity and allowing low-fee secure closing (congestion control).
• CTV is the most mature of the covenant proposals and has been tested and reviewed for several years.
• It is designed to not enable recursive covenants, but with CAT, CTV can be adapted to recursive covenants. While CAT alone can support recursive covenants, CAT covenants are large and complex. On the other hand, CTV+CAT covenants are small and simple.

When designing, building and operating Arwen (a protocol for a non-custodial exchange built from payment channel and cross-chain atomic swaps) we would have benefited from the congestion control feature of CTV. CTV would have allowed us to design a protocol which settle our CLTV-based payment channels prior to the timelock expiring even under extreme spikes in transaction fee rates. Without CTV we always faced the possibility that the fees would spike above the incoming channel value and prepaid fee escrow, forcing us to charge our users a much higher fee escrow.

OP_CSFS

Prefer

Pros:

• The ability to check signatures on arbitrary data in a script is a useful general-purpose opcode. I have wished for such a think many times when writing Bitcoin protocols, e.g. TumbleBit (Blind Signture Coin Swaps) would have been far less complex if Bitcoin had CSFS.
• By itself CSFS does not enable covenants, but it is a useful tool to have in covenant design.

OP_PAIRCOMMIT

Weak

Pros:

• Designed to be a less powerful version of CAT, thus gaining some of the benefits of CAT without enabling all the features of CAT, i.e., general computation.
• I don't see any reason not to do PAIRCOMMIT, it is better than nothing. That said, if CAT is to be merged at some point in the future, then PAIRCOMMIT would have almost no utility beyond using slightly fewer opcodes for very specific usecases.

Cons:

• The argument for PAIRCOMMIT seems predicated on the idea that the Bitcoin community does not want the expressiveness of CAT, if we assume this is the case, then we should be very careful PAIRCOMMIT does not enable this expressiveness as well. On the other hand, if the Bitcoin community does want CAT, then we should merge CAT rather than PAIRCOMMIT. PAIRCOMMIT is well designed to be less powerful than CAT and it is likely that you can not simulate CAT with PAIRCOMMIT. That said, I am not convinced it is impossible that there is no way to simulate CAT with PAIRCOMMIT, nor I do feel confident that I know how much less powerful PAIRCOMMIT is than CAT.

OP_INTERNALKEY

Prefer

Pros:

• Can be used to save 8v Bytes of blockspace and pay lower fees with no drawbacks.

OP_CAT

Prefer

• CAT is simple in terms of implementation in the Bitcoin codebase. As such it is unlikely introduce much of a support burden on bitcoin-core and we can be fairly sure it is unlikely to have bugs.
• Pairs well with covenent-specific opcodes such as TXHASH and CTV. CAT is very useful for enforcement custom covenant rules because it enables both merkle trees in Bitcoin tapscript, math of numbers greater than 32-bits and the ability to match substrings instead of transaction data. The CTV BIP BIP-119 details seven different ways CAT would improve the functionality or efficency of CTV. It is likely that any covenant-specific proposal will also benefit from CAT.
• CAT is a useful tool for anyone writing scripts in general. The benefits of CAT extend well beyond covenants.
• Counter-intuitively a major advantage of CAT is that building covenants using CAT is both complex and inefficient in terms of block space and transaction fee. See full explanation below.

Cat covenants are expensive and this is a good thing

Counterintuitively a major advantage of CAT is that building covenants using CAT is both complex and inefficient in terms of block space and transaction fee. I see this as the biggest benefit of CAT brings to covenants. Bitcoin is unlikely to get a redo on an covenant-specific opcode. Thus, it is important that we get the covenant opcode right the first time. The risk is that the covenant-specific opcode misses critical use case or desired functionality we didn't know we needed. This presents a chicken and the egg problem: businesses and researchers aren't going to invest significant resources into covenants until they are sure Bitcoin will support them, but getting a covenant specific opcode right requires actually that sort of activity.

This provides several benefits to covenants:

1. CAT solves this chicken and egg problem. CAT enables covenants without being a covenant specific opcode. This means people can build businesses and complex protocols once CAT if enable and then we can use that information to design the right covenant specific opcode. CAT let's us learn lessons early.
2. CAT lets us patch issues in covenants. Let's say after merging some covenant opcode someone invents a protocol that the covenant opcode can't support. CAT makes covenants more flexible letting us patch this missing feature.
3. CAT lets us put our toes in the covenant water without fully committing. I'm in favor of covenants, but not everyone is. Say we discover that covenants hurt decentralization, CAT covenants are expensive and clunky which limits the damage. On the other hand, if CAT covenants are being used and the sky isn't falling, the case for enabling a covenant specific opcode becomes easier.

OP_CCV

Evaluating

OP_VAULT

Prefer

• Vaults provide a security upgrade for Bitcoin custodians and those who self-custody bitcoin. Securing bitcoins is an extremely difficult job.
• While other covenant opcodes enable vaults, it is worthwhile to have an opcode that directly supports the vault usecase to make it as easy and simple for custodians to support as possible.

OP_TXHASH

Prefer

• Enables general purpose introspection into the spending transaction. This enables recursive covenants. Such an opcode would be an valuable enhancement to Tapscript.

SIGHASH_APO

Evaluating