Prelude

Soft forks tighten the rule set of what transactions are valid. Additional opcodes allow existing owners of coins to put additional constraints on how those coins are spent.

Many covenant-enabling opcodes are nothing more than "new", more specific sighashes¹. Other opcodes allow access to information about a spending transaction.

None of this is conceptually objectionable. People should be able to put constraints on their property. But first we must do no harm.

The concrete issues when gauging additional script functionality are:

• "externality" risk - is enforcing this new rule going to make bitcoin somehow exploitable?
• "code carry" risk - once a rule is added to bitcoin, it must be enforced forever, or else a hardfork takes place. Is the code going to pose some kind of awful maintenance burden?

These two risks are, for all outstanding covenant proposals, essentially implementation risks (aside from maybe OP_CAT, which I'll talk about).

Because of script size limits and block constraints, many other, more fundamental externality risks of script execution just aren't an issue in the way that they would be on a less constrained blockchain.

All that said...

OP_CTV

Prefer

In a nutshell, CTV allows you to say "these coins are only spendable by the following set of possible transactions." It turns out this is really, really useful in a number of different contexts:

• Precomputed vaults: to emulate vaults with presigned transactions, custodians must presign vault graphs with ephemeral keys, and then delete the keys. Since you can't really prove key deletion, auditors hate vaults. CTV removes this need.
• Usable-by-individual-people vaults: For "better" vaults that are actually usable by real people, CTV is crucial. From BIP-345: "During the withdrawal process, the proposed final destination for value being withdrawn must be committed to. OP_CTV is the simplest, safest way to commit the spend of some coins to a particular set of outputs. An earlier version of this proposal attempted to use a simpler, but similar method, of locking the spend of coins to a set of outputs, but this method introduced txid malleability."
• Massive DLC optimization (x.com/matthewjablack…)
• Applications for timeout trees and second-layer systems like Ark
• Non-interactive lightning channel setup
• Used with CSFS to allow eltoo (not that I'm sure anyone actually cares)
• Congestion control: a speculative but potentially crucial tool for facilitating highly compressed use of chain space to get people "out" of systems if there is correlated failure in a third party custodian, whether that's a conventional exchange or some kind of programmatic construct like a Lightning channel (remember the 0-days in LND?).
  • A slightly deeper spectulation is that CC could eventually be used to smooth out the fee market, which may give miners less of an incentive to try reorg battles during times of low fees. But that one is certainly speculative.

I could go on, but it should already be apparent that so many uses across such a diverse set of applications attests to the fact that we just keep discovering that this thing is really useful.

And it's simple. And it's upgradeable. And people have been trying to break it for years, and can't.

This should have been activated a year ago probably.

OP_CHECKSIGFROMSTACK (CSFS)

Prefer

Bitcoin's CHECKSIG is basically the core of how most coins are moved. All CSFS does is takes that same signature checking operation, and allows it over an arbitrary message using an arbitrary pubkey. As long as it's costed properly, it's basically safe by definition. Elements has had CHECKSIGFROMSTACK deployed since 2017.

It's the kind of op that probably just should have been in bitcoin all along.

Uses:

• Key delegation: "allow someone to spend this coin if their key is signed by mine" probably has some cool statechain use
• Eltoo: along with CTV, CSFS lets you do eltoo
• Other uses spelled out at Optech: https://bitcoinops.org/en/topics/op_checksigfromstack/

OP_PAIRCOMMIT

Weak

This is a special form of OP_CAT that is constructed (I think?) solely to enable eltoo.

This is emblematic of a certain class of proposals for me: I don't consider them any kind of technical risk to bitcoin, safe to deploy, low code burden, etc. etc. But they're just kind of goofy.

This feels like a very special-cased opcode that is just trying to skirt ghosts of OP_CAT that I don't think are actually worth worrying about.

I'd be fine if this was in bitcoin, but let's just get real and do OP_CAT instead.

OP_INTERNALKEY

Prefer

Another completely inoffensive, three-line opcode that probably should have just come with Taproot. All this thing does is push the Taproot internal key to the stack. It saves many script bytes when we want to make some kind of assertion about the Taproot structure. No downsides.

There is an application for this when implementing eltoo (again, if anyone cares) with CTV+CSFS, but I can see how, like CTV, this is a very general, simple tool that will have uses in many disparate applications.

OP_CAT

Acceptable

I hated CAT when its discussion (re)started, and I still hate it in a very real sense, but its time has come.

OP_CAT enables covenants in the same way that having an arbitrary number of black and white pebbles allows you to build an x86 computer. But some people are okay paying for that, and probably much better to have the option than not.

I used to have vague worries about MEV, but some combination of script size limits, the slow 10 minute block time, and the UTXO (vs. account) model really limits the byzantine mischief that ETH people and other assorted cartoon characters can bring to the chain.

CAT is a necessary admission that the consensus process is calcifying, and we are in need of a permissionless escape hatch (however stupid) to continue to innovate. It's also harmless due to script size limits.

OP_CCV

Wanting

I am very supportive of OP_CHECKCOVENANTVERIFY, especially if it's a more general mechanism that can absorb OP_VAULT uses but also be useful for other things.

The problem is that

It may well be that OP_VAULT gets folded somehow into OP_CCV as an application, and I'd welcome that. But it remains to be seen.

OP_VAULT

Acceptable/Prefer

I've written at length, and will continue to write, about how important vaults are. My industry experience is intimately linked with this stuff, and I honestly can't see a user of bitcoin whose experience wouldn't improve given the presence of something like OP_VAULT.

You can get part of the way there with CTV and CAT, but there are crucial usability and efficiency differences that those two simply won't get you relative to the OP_VAULT construction. These are:

• Easy address reuse: CTV, for example, will burn funds if you reuse vault addresses,
• Arbitrary partial withdrawals ("revaults"): CTV can't do this, CAT can maybe do it as long as the math doesn't require 64 bit,
• Batched triggering: an important efficiency gain where many number of vault outputs are spent by the same unvaulting process (CTV can't do this; CAT can do it within certain amounts and up to say 8 inputs),
• No horribly confusing scripts (only mildly confusing scripts) and metadata retention processes

To date, the OP_VAULT vault construction is the only vault that I would personally use, although I do think CTV vaults could be useful in an industrial context. I would never recommend CAT vaults for use because the scripts are so inscrutable, but maybe after years and years of cooling period and better tooling, there could emerge a (relatively inefficient) construction that people do feel okay about using.

The problem with OP_VAULT right now is that it is a relatively heavyweight change compared to, say, CAT and CTV. I think it's well specified and well tested, and probably has more review than many of these other proposals. But it still doesn't feel like it yet has the momentum for immediate activation.

Sometimes I feel frustrated that I can see, tangibly, how much better a custody experience this could provide for bitcoin, but not enough people at this point do and that's life. You can't push a string.

OP_TXHASH

Deficient

This is an interesting one. Another category of opcodes is: "in conceptual terms I support having something like this in bitcoin, but the implementation is just too complex and the proposed usecases too unspecified."

Conceptually, you should be able to dictate as granular a sighash as you want in bitcoin. This is basically what TXHASH does.

The snag is twofold:

1. this results in a complicated piece of code that has numerous open questions about how necessary it is to cache things to avoid issues like quadratic sighash (fjahr.com/posts/how-segw…), and
2. I haven't heard a clear articulation of the uses over and above CTV, which TXHASH is basically just a more general version of.

If great uses get pitched and people get excited and it really does seem worth the effort to have super flexible sighashing in bitcoin, I'm all for it. But it will take a good amount of work to make sure that code isn't going to cause problems.

SIGHASH_APO

Weak

Basically obviated by better alternatives (CTV+CSFS), but if the question is "nothing vs. APO," I'll take APO every time.

Footnotes