What are the risks of OP_VAULT?

Question

In the past it has been argued that some covenant schemes could be risky. However AFAIK OP_VAULT is a very specific and limited construction.

What are the risks associated with it, if any?

Answer 1

The design of OP_VAULT at the time of writing (April 2023) seems to be in flux and isn't yet finalized. Unlike OP_CTV it is a recursive covenant opcode and the safety of recursive covenants has been discussed extensively on the bitcoin-dev mailing list. It shouldn't pose a network risk or a DoS vector to a node verifying OP_VAULT rules (assuming it was activated on mainnet).

The axis that is more relevant to these more limited covenant opcodes is the utility axis rather than the safety axis i.e. when compared to competing alternatives (SIGHASH_ANYPREVOUT, OP_TLUV, OP_TXHASH and OP_CHECKSIGFROMSTACKVERIFY etc) is this the optimal proposal for enabling this kind of functionality? Burak posted that OP_VAULT functionality could be emulated by other opcodes currently active on Elements.

The design space for opcodes is very large and we can't/shouldn't enable every single possible opcode on mainnet. For more explanation on why see this post. Hence the major risk here is probably that no one would end up using it especially if an alternative superior proposal was activated some time later. And having a slightly inferior proposal active onchain may impact whether that alternative superior proposal ends up getting activated at all. Hence there are lots of factors to consider and assuming we don't want to clog up the consensus rules with lots of unused opcodes we should be extremely selective on what we end up activating on mainnet (ignoring the activation chain split risks that are present with every attempted activation).

There are risks and trade-offs when assessing whether to use a particular vault design that could impact the usage of a covenant opcode like OP_VAULT. Some of the risks of using the Revault vault design are discussed here. However, these aren't systemic risks to the network, just risks to the user of a particular vault design.

edit (September 2023): A tweet thread on OP_VAULT by James O'Beirne is here.

Answer 2

I think the main risk with activating a "feature-specific" opcode, like OP_VAULT, is that users will at some point find out a better way to do "vaults" and the opcode won't support it. By the very nature of softforks, users and developers only really start to use the new feature after it is activated. Thinkers, protocol developers etc might conceptualize use-cases and develop proof-of-concepts, but the truth is that the majority of actual usage comes after activation and with it comes all the creative brain power of people figuring out what they actually want to do.

It's very much possible that when OP_VAULT activates, we realize that there is a sub-optimal aspect to the implementation that now everyone has to stick with. It means that "vaults v2" requires a new version of the opcode and another softfork.

This of course not an answer to "how could the Bitcoin community suffer from the activation of OP_VAULT", but rather "how could the Bitcoin community suffer from the activation of OP_VAULT instead of more general introspection-enabling mechanisms".