Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9818AC002F for ; Sat, 15 Jan 2022 17:19:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 76F3C401F2 for ; Sat, 15 Jan 2022 17:19:41 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=tutanota.de Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiuJx0YbpYgJ for ; Sat, 15 Jan 2022 17:19:39 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162]) by smtp2.osuosl.org (Postfix) with ESMTPS id 8F3D640004 for ; Sat, 15 Jan 2022 17:19:39 +0000 (UTC) Received: from w3.tutanota.de (unknown [192.168.1.164]) by w1.tutanota.de (Postfix) with ESMTP id 819E4FA00BC for ; Sat, 15 Jan 2022 17:19:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1642267176; s=s1; d=tutanota.de; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Cc:Date:Date:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:Sender; bh=RuYcRi9xjP5UQvOPcOIJcqEsyhTtH/aqOsr7qqq3w4c=; b=YaI7+SHBLeSa7JFSfRqg3mKGqaBSQhTmZ6cbAuSFnZmbrIixvasrUlfvRlJzObMH ojE9LANSlYcM/4+o9KE/v38LxDkgLnicTz1GjAERq7w/a2EJX0k89CStPdq1GyJ8Q41 XtYp5VzeyThKnpQTedmtsYLZcF300T/Clhz9a1VQhq6Nu1N6dgx/nqbIYr+e74z0sg7 UE2T0qM4Gw97AD1gneB/4GUZIkAP8ChJk8MO9qV8IxWmYiXnoJXxGVgXwwN2or1gTRT OzHHlrm/3PYXSSkyeLH0hcPI5YhgG57OGvMnQAIXsxzEKJHWrHPm1IrdKiJv3xKncb6 pQzR1MGJgw== Date: Sat, 15 Jan 2022 18:19:36 +0100 (CET) From: Prayank To: Bitcoin Dev Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_198831_1473189489.1642267176519" X-Mailman-Approved-At: Sat, 15 Jan 2022 22:26:13 +0000 Subject: [bitcoin-dev] CTV and ANYPREVOUT vault designs X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2022 17:19:41 -0000 ------=_Part_198831_1473189489.1642267176519 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Everything shared in this email was earlier posted by Michael Folkson on Bi= tcoin Stackexchange (a site that allows people to close opinion based quest= ions), cross posting here so that more developers could discuss and in a be= tter way. I have just removed one paragraph. At the time of writing (January 2022) there seems to be very little researc= h with direct comparisons on the utility and safety of different ways to en= able the construction of various vault designs. Indeed the covenant opcode = TAPLEAF_UPDATE_VERIFY was only [proposed][1] to the bitcoin-dev mailing lis= t 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 tha= t it enables a vault design that matches a previous [vault design][2] of Br= yan 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 beca= me OP_CHECKTEMPLATEVERIFY) as a "rudimentary, limited form of covenant whic= h does not bear the same technical and social risks of prior covenant desig= ns". This suggests that for vaults specifically the design space may be mor= e limited using OP_CHECKTEMPLATEVERIFY. Andrew Poelstra has blogged on how to use OP_CAT and OP_CHECKSIGFROMSTACK t= o construct covenants and vaults ([1][5], [2][3]). These would enable more = generalized covenants than OP_CHECKTEMPLATEVERIFY potentially increasing th= e design space for vaults but with the downsides of being less efficient an= d arguably riskier. There does seem to be a direct risk/reward trade-off he= re when attempting to broaden the design space for vaults and it is difficu= lt to assess where on the spectrum is the potential optimum given how few v= ault prototypes there are let alone fully built out implementations of thos= e prototypes.=C2=A0 The solitary [paper][6] that has compared building vaults using OP_CHECKTEM= PLATEVERIFY and SIGHASH_ANYPREVOUT at the time of writing is **Bitcoin Cove= nants: Three Ways to Control the Future**. This paper discussed three categories of vault design: deleted key (no cons= ensus changes required but inferior security model), recovered key (require= s BIP 118 consensus change, superior security model) and script based (requ= ires BIP 119 consensus change, superior security model). [![Bitcoin Covenants Paper][7]][7] It stated: > Recovered-key and script-based covenants are mostly functionally equivale= nt and so the advantages that recovered-key covenants have over deleted-key covena= nts also applies to Script-based covenants. If either were enabled by their required soft-fork upgrade then a new domain o= f 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=E2=80=99s > 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. =C2=A0 [1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Se= ptember/019419.html =C2=A0 [2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-Au= gust/017231.html =C2=A0 [3]: https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i= i.html =C2=A0 [4]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-Ma= y/016934.html =C2=A0 [5]: https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i= .html =C2=A0 [6]: https://arxiv.org/pdf/2006.16714.pdf =C2=A0 [7]: https://i.stack.imgur.com/Udey1.png --=20 Prayank A3B1 E430 2298 178F ------=_Part_198831_1473189489.1642267176519 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 s= eems to be very little research with direct comparisons on the utility and = safety of different ways to enable the construction of various vault design= s. Indeed the covenant opcode TAPLEAF_UPDATE_VERIFY was only [proposed][1] = to the bitcoin-dev mailing list in September 2021 and there are no implemen= tations of it as yet let alone detailed analyses of how it compares to cons= tructing vaults using SIGHASH_ANYPREVOUT or OP_CHECKTEMPLATEVERIFY. The mai= ling list post did suggest that it enables a vault design that matches a pr= evious [vault design][2] of Bryan Bishop with additional benefits:

> It's fully recursive, a= llows 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.
<= /div>

Jeremy Rubin initially [= described][4] OP_CHECKOUTPUTSHASHVERIFY (which became OP_CHECKTEMPLATEVERIF= Y) 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_CHECK= TEMPLATEVERIFY.

Andr= ew Poelstra has blogged on how to use OP_CAT and OP_CHECKSIGFROMSTACK to co= nstruct covenants and vaults ([1][5], [2][3]). These would enable more gene= ralized covenants than OP_CHECKTEMPLATEVERIFY potentially increasing the de= sign space for vaults but with the downsides of being less efficient and ar= guably riskier. There does seem to be a direct risk/reward trade-off here w= hen attempting to broaden the design space for vaults and it is difficult t= o assess where on the spectrum is the potential optimum given how few vault= prototypes there are let alone fully built out implementations of those pr= ototypes. 

The = solitary [paper][6] that has compared building vaults using OP_CHECKTEMPLAT= EVERIFY and SIGHASH_ANYPREVOUT at the time of writing is **Bitcoin Covenant= s: Three Ways to Control the Future**.

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

[![Bitcoin Covenant= s Paper][7]][7]

It s= tated:

> Recovere= d-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
<= /div>
either were enabled by their required soft-fork upgr= ade then a new domain of practical covenant-based protocols could emerge.
Understanding precisely what utility is gained fr= om such upgrades is key to their progress.

<= /div>
The paper concluded by stating:

> Bitcoin is a complex adaptive syste= m with many interacting parts and
> there are= systemic risks with every modification of bitcoin=E2=80=99s
> 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= .

  [6]: https://arxiv.org/pdf/2006.16714.pdf

--=
Prayank

A3B1 E430= 2298 178F
------=_Part_198831_1473189489.1642267176519--