Everything shared in this email was earlier posted by Michael Folkson on Bitcoin Stackexchange (a site that allows people to close opinion based questions), cross posting here so that more developers could discuss and in a better way. I have just removed one paragraph.
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][1] 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][2] 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][4] 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][5], [2][3]). 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][6] 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][7]][7] 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 analyze those risks and it > would be hubris to claim that there are no unknown risks being > introduced. [1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019419.html [2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017231.html [3]: https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html [4]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016934.html [5]: https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html [6]: https://arxiv.org/pdf/2006.16714.pdf [7]: https://i.stack.imgur.com/Udey1.png -- Prayank A3B1 E430 2298 178F
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
