path: root/15/357aa87e6450d87812424e21b6fac6d4259e99

Return-Path: <prayank@tutanota.de>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 9818AC002F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <prayank@tutanota.de>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <MtTk5Er--3-2@tutanota.de>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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

<html>
  <head>
    <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF-8=
">
  </head>
  <body>
<div>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.<br></div><div dir=3D"auto=
"><br></div><div dir=3D"auto">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:<br></div=
><div dir=3D"auto"><br></div><div dir=3D"auto">&gt; It's fully recursive, a=
llows withdrawals to vary rather than be the<br></div><div dir=3D"auto">&gt=
; fixed amount L (due to not relying on pre-signed transactions), and<br></=
div><div dir=3D"auto">&gt; generally seems a bit simpler to work with.<br><=
/div><div dir=3D"auto"><br></div><div dir=3D"auto">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.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">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.&nbsp;<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">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**.<br></div><div dir=3D"auto"><br></div=
><div dir=3D"auto">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).=
<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">[![Bitcoin Covenant=
s Paper][7]][7]<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">It s=
tated:<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">&gt; Recovere=
d-key and script-based covenants are mostly functionally equivalent and<br>=
</div><div dir=3D"auto">so the advantages that recovered-key covenants have=
 over deleted-key covenants also applies to Script-based covenants. If<br><=
/div><div dir=3D"auto">either were enabled by their required soft-fork upgr=
ade then a new domain of practical covenant-based protocols could emerge.<b=
r></div><div dir=3D"auto">Understanding precisely what utility is gained fr=
om such upgrades is key to their progress.<br></div><div dir=3D"auto"><br><=
/div><div dir=3D"auto">The paper concluded by stating:<br></div><div dir=3D=
"auto"><br></div><div dir=3D"auto">&gt; Bitcoin is a complex adaptive syste=
m with many interacting parts and<br></div><div dir=3D"auto">&gt; there are=
 systemic risks with every modification of bitcoin=E2=80=99s<br></div><div =
dir=3D"auto">&gt; code-base and protocol. It is difficult to analyze those =
risks and it<br></div><div dir=3D"auto">&gt; would be hubris to claim that =
there are no unknown risks being<br></div><div dir=3D"auto">&gt; introduced=
.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">&nbsp; [1]: <a hre=
f=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September=
/019419.html">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-=
September/019419.html</a><br></div><div dir=3D"auto">&nbsp; [2]: <a href=3D=
"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017231=
.html">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/=
017231.html</a><br></div><div dir=3D"auto">&nbsp; [3]: <a href=3D"https://w=
ww.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html">https://www.w=
psoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html</a><br></div><div =
dir=3D"auto">&nbsp; [4]: <a href=3D"https://lists.linuxfoundation.org/piper=
mail/bitcoin-dev/2019-May/016934.html">https://lists.linuxfoundation.org/pi=
permail/bitcoin-dev/2019-May/016934.html</a><br></div><div dir=3D"auto">&nb=
sp; [5]: <a href=3D"https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-=
tricks-i.html">https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-trick=
s-i.html</a><br></div><div dir=3D"auto">&nbsp; [6]: <a href=3D"https://arxi=
v.org/pdf/2006.16714.pdf">https://arxiv.org/pdf/2006.16714.pdf</a><br></div=
><div dir=3D"auto">&nbsp; [7]: <a href=3D"https://i.stack.imgur.com/Udey1.p=
ng">https://i.stack.imgur.com/Udey1.png</a><br></div><div><br></div><div>--=
 <br></div><div>Prayank<br></div><div><br></div><div dir=3D"auto">A3B1 E430=
 2298 178F<br></div>  </body>
</html>

------=_Part_198831_1473189489.1642267176519--