<p>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 <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019419.html" rel="nofollow noreferrer">proposed</a> 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 <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017231.html" rel="nofollow noreferrer">vault design</a> of Bryan Bishop with additional benefits:</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>Jeremy Rubin initially <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016934.html" rel="nofollow noreferrer">described</a> OP_CHECKOUTPUTSHASHVERIFY (which became OP_CHECKTEMPLATEVERIFY) as a &quot;rudimentary, limited form of covenant which does not bear the same technical and social risks of prior covenant designs&quot;. This suggests that for vaults specifically the design space may be more limited using OP_CHECKTEMPLATEVERIFY.</p>
<p>Andrew Poelstra has blogged on how to use OP_CAT and OP_CHECKSIGFROMSTACK to construct covenants and vaults (<a href="https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html" rel="nofollow noreferrer">1</a>, <a href="https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html" rel="nofollow noreferrer">2</a>). 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.</p>
<p>The solitary <a href="https://arxiv.org/pdf/2006.16714.pdf" rel="nofollow noreferrer">paper</a> that has compared building vaults using OP_CHECKTEMPLATEVERIFY and SIGHASH_ANYPREVOUT at the time of writing is <strong>Bitcoin Covenants: Three Ways to Control the Future</strong>.</p>
<p>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).</p>
<p><a href="https://i.sstatic.net/Udey1.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/Udey1.png" alt="Bitcoin Covenants Paper" /></a></p>
<p>It stated:</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>The paper concluded by stating:</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>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.</p>
<p><strong>April 2023 update</strong></p>
<p>There is now an additional <a href="https://jameso.be/vaults.pdf" rel="nofollow noreferrer">paper</a> authored by James O'Beirne on &quot;Vaults and Covenants&quot; and a draft BIP (<a href="https://github.com/bitcoin/bips/pull/1421" rel="nofollow noreferrer">BIP 345</a>) which introduces new opcodes including OP_VAULT. James has a <a href="https://github.com/jamesob/simple-ctv-vault" rel="nofollow noreferrer">demo vault</a> using OP_CTV and darosior has built that same vault <a href="https://github.com/darosior/simple-anyprevout-vault" rel="nofollow noreferrer">using ANYPREVOUT</a> instead at the expense of additional virtual bytes.</p>

CC BY-SA 4.0
2022-01-15T16:10:59.527Z
@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.
Michael Folkson
CC BY-SA 4.0
2022-01-15T16:14:09.703Z
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)
Michael Folkson
CC BY-SA 4.0
2022-01-15T16:20:18.950Z
Maybe the research is mainly opinion based from (arguably) qualified people currently. On that I would probably agree with you. But that is the state of the research. I can't do much about that. On the last paragraph I am happy to edit. The last line is my personal view but I outline there is disagreement with me on this. You or anyone else is free to post an alternative answer summarizing the current state of the research.
Michael Folkson
CC BY-SA 4.0
2022-01-15T16:53:45.807Z
I'm not sure what you are asking. The resources I summarize or quote from are all public. You are free to send an email to the mailing list discussing any of these resources though obviously I'd recommend you link to their work and attribute them if you do.
Michael Folkson
CC BY-SA 4.0
2022-01-15T15:53:16.267Z
2023-04-17T13:50:06.723Z
2023-04-17T13:50:06.723Z
Michael Folkson
<p>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?</p>

<bip118-sighash-anyprevout><bip119-checktemplateverify><covenants>
How do ANYPREVOUT and CTV compare when considering how useful they are for vault designs?
Michael Folkson
# How do ANYPREVOUT and CTV compare when considering how useful they are for vault designs?

(Asked by: username_0 on 2021-12-29)

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?

**Tags:** bip118-sighash-anyprevout, bip119-checktemplateverify, covenants


---

## 1 answers

### Answer by username_0 on 2022-01-15. Score: 0 | Accepted answer

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](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019419.html) 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](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017231.html) 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](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016934.html) 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](https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html), [2](https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html)). 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](https://arxiv.org/pdf/2006.16714.pdf) 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](https://i.sstatic.net/Udey1.png)](https://i.sstatic.net/Udey1.png)

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](https://jameso.be/vaults.pdf) authored by James O'Beirne on "Vaults and Covenants" and a draft BIP ([BIP 345](https://github.com/bitcoin/bips/pull/1421)) which introduces new opcodes including OP\_VAULT. James has a [demo vault](https://github.com/jamesob/simple-ctv-vault) using OP\_CTV and darosior has built that same vault [using ANYPREVOUT](https://github.com/darosior/simple-anyprevout-vault) instead at the expense of additional virtual bytes.

> **Comments:**
> **username_0**: @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.  
> **username_0**: 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)  
> **username_0**: Maybe the research is mainly opinion based from (arguably) qualified people currently. On that I would probably agree with you. But that is the state of the research. I can't do much about that. On the last paragraph I am happy to edit. The last line is my personal view but I outline there is disagreement with me on this. You or anyone else is free to post an alternative answer summarizing the current state of the research.  
> **username_0**: I'm not sure what you are asking. The resources I summarize or quote from are all public. You are free to send an email to the mailing list discussing any of these resources though obviously I'd recommend you link to their work and attribute them if you do.  

---

