What is the latest state of vault research on how useful SIGHASH_ANYPREVOUT and OP_CTV are with regards to existing vault designs? Are new alternatives e.g. TapleafUpdateVerify (TLUV) currently considered more or less useful for existing vault designs?

1 Answer 1


At the time of writing (January 2022) there seems to be very little research with direct comparisons on the utility and safety of different ways to enable the construction of various vault designs. Indeed the covenant opcode TAPLEAF_UPDATE_VERIFY was only proposed to the bitcoin-dev mailing list in September 2021 and there are no implementations of it as yet let alone detailed analyses of how it compares to constructing vaults using SIGHASH_ANYPREVOUT or OP_CHECKTEMPLATEVERIFY. The mailing list post did suggest that it enables a vault design that matches a previous vault design of Bryan Bishop with additional benefits:

It's fully recursive, allows withdrawals to vary rather than be the fixed amount L (due to not relying on pre-signed transactions), and generally seems a bit simpler to work with.

Jeremy Rubin initially described OP_CHECKOUTPUTSHASHVERIFY (which became OP_CHECKTEMPLATEVERIFY) as a "rudimentary, limited form of covenant which does not bear the same technical and social risks of prior covenant designs". This suggests that for vaults specifically the design space may be more limited using OP_CHECKTEMPLATEVERIFY.

Andrew Poelstra has blogged on how to use OP_CAT and OP_CHECKSIGFROMSTACK to construct covenants and vaults (1, 2). These would enable more generalized covenants than OP_CHECKTEMPLATEVERIFY potentially increasing the design space for vaults but with the downsides of being less efficient and arguably riskier. There does seem to be a direct risk/reward trade-off here when attempting to broaden the design space for vaults and it is difficult to assess where on the spectrum is the potential optimum given how few vault prototypes there are let alone fully built out implementations of those prototypes.

The solitary paper that has compared building vaults using OP_CHECKTEMPLATEVERIFY and SIGHASH_ANYPREVOUT at the time of writing is Bitcoin Covenants: Three Ways to Control the Future.

This paper discussed three categories of vault design: deleted key (no consensus changes required but inferior security model), recovered key (requires BIP 118 consensus change, superior security model) and script based (requires BIP 119 consensus change, superior security model).

Bitcoin Covenants Paper

It stated:

Recovered-key and script-based covenants are mostly functionally equivalent and so the advantages that recovered-key covenants have over deleted-key covenants also applies to Script-based covenants. If either were enabled by their required soft-fork upgrade then a new domain of practical covenant-based protocols could emerge. Understanding precisely what utility is gained from such upgrades is key to their progress.

The paper concluded by stating:

Bitcoin is a complex adaptive system with many interacting parts and there are systemic risks with every modification of bitcoin’s code-base and protocol. It is difficult to analyse those risks and it would be hubris to claim that there are no unknown risks being introduced.

I know some will disagree including most likely BIP 119's author (Jeremy Rubin) but it appears that on both the utility axis and the safety axis there appears to be a lot more exploration and analysis to do to converge on a tool or set of tools to enable the construction of vaults on Bitcoin mainnet which wouldn't soon afterwards be assessed to be suboptimal. We then get into a high level discussion of whether we should see Bitcoin mainnet as a testbed for new use cases that may or may not work out or whether we should see Bitcoin mainnet as a place where consensus changes are made when there is strong confidence that those changes will stand the test of time on both the utility and safety axes. Personally I lean towards the latter but that is an entire other discussion in itself.

April 2023 update

There is now an additional paper authored by James O'Beirne on "Vaults and Covenants" and a draft BIP (BIP 345) which introduces new opcodes including OP_VAULT. James has a demo vault using OP_CTV and darosior has built that same vault using ANYPREVOUT instead at the expense of additional virtual bytes.

  • 1
    Isn't this Q&A opinion based? Or there was some change in Bitcoin Stackexchange rules recently that I am unaware of?
    – user103136
    Commented Jan 15, 2022 at 16:06
  • @Prayank: What particular part of it is opinion based? It is summarizing the existing research other than the last paragraph which states there isn't much research (this is a fact) and hence outlines there are opposing views on whether this limited amount of research is enough to consider consensus changes. If you find any other research feel free to link to it or write your own answer. Commented Jan 15, 2022 at 16:10
  • Now you could say that it includes opinions from arguably qualified people like Jeremy Rubin, Andrew Poelstra, AJ Towns, authors of the covenant paper. Ideally there would be a lot more evidence to justify those opinions (I wish there was personally) but that is the state of the research (which was the original question) Commented Jan 15, 2022 at 16:14
  • 1
    I would prefer discussing this on Bitcoin dev mailing list and how "useful" some covenants could be in future which includes some still being developed is opinion based IMO. Last paragraph, your opinion on BIP 119 shared on mailing list and other things could be ignored but I have observed such questions being closed in past so wanted to make sure there is nothing that I am missing here.
    – user103136
    Commented Jan 15, 2022 at 16:16
  • 1
    Hope you don't mind if I share it on mailing list? Not the link but the content for further discussion.
    – user103136
    Commented Jan 15, 2022 at 16:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.