357aa87e6450d87812424e21b6fac6d4259e99
1 Return-Path: <prayank@tutanota.de> 2 Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) 3 by lists.linuxfoundation.org (Postfix) with ESMTP id 9818AC002F 4 for <bitcoin-dev@lists.linuxfoundation.org>; 5 Sat, 15 Jan 2022 17:19:41 +0000 (UTC) 6 Received: from localhost (localhost [127.0.0.1]) 7 by smtp2.osuosl.org (Postfix) with ESMTP id 76F3C401F2 8 for <bitcoin-dev@lists.linuxfoundation.org>; 9 Sat, 15 Jan 2022 17:19:41 +0000 (UTC) 10 X-Virus-Scanned: amavisd-new at osuosl.org 11 X-Spam-Flag: NO 12 X-Spam-Score: 0.601 13 X-Spam-Level: 14 X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 15 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 16 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 17 RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 18 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 19 autolearn=ham autolearn_force=no 20 Authentication-Results: smtp2.osuosl.org (amavisd-new); 21 dkim=pass (2048-bit key) header.d=tutanota.de 22 Received: from smtp2.osuosl.org ([127.0.0.1]) 23 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) 24 with ESMTP id ZiuJx0YbpYgJ 25 for <bitcoin-dev@lists.linuxfoundation.org>; 26 Sat, 15 Jan 2022 17:19:39 +0000 (UTC) 27 X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 28 Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162]) 29 by smtp2.osuosl.org (Postfix) with ESMTPS id 8F3D640004 30 for <bitcoin-dev@lists.linuxfoundation.org>; 31 Sat, 15 Jan 2022 17:19:39 +0000 (UTC) 32 Received: from w3.tutanota.de (unknown [192.168.1.164]) 33 by w1.tutanota.de (Postfix) with ESMTP id 819E4FA00BC 34 for <bitcoin-dev@lists.linuxfoundation.org>; 35 Sat, 15 Jan 2022 17:19:36 +0000 (UTC) 36 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1642267176; 37 s=s1; d=tutanota.de; 38 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; 39 bh=RuYcRi9xjP5UQvOPcOIJcqEsyhTtH/aqOsr7qqq3w4c=; 40 b=YaI7+SHBLeSa7JFSfRqg3mKGqaBSQhTmZ6cbAuSFnZmbrIixvasrUlfvRlJzObMH 41 ojE9LANSlYcM/4+o9KE/v38LxDkgLnicTz1GjAERq7w/a2EJX0k89CStPdq1GyJ8Q41 42 XtYp5VzeyThKnpQTedmtsYLZcF300T/Clhz9a1VQhq6Nu1N6dgx/nqbIYr+e74z0sg7 43 UE2T0qM4Gw97AD1gneB/4GUZIkAP8ChJk8MO9qV8IxWmYiXnoJXxGVgXwwN2or1gTRT 44 OzHHlrm/3PYXSSkyeLH0hcPI5YhgG57OGvMnQAIXsxzEKJHWrHPm1IrdKiJv3xKncb6 45 pQzR1MGJgw== 46 Date: Sat, 15 Jan 2022 18:19:36 +0100 (CET) 47 From: Prayank <prayank@tutanota.de> 48 To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> 49 Message-ID: <MtTk5Er--3-2@tutanota.de> 50 MIME-Version: 1.0 51 Content-Type: multipart/alternative; 52 boundary="----=_Part_198831_1473189489.1642267176519" 53 X-Mailman-Approved-At: Sat, 15 Jan 2022 22:26:13 +0000 54 Subject: [bitcoin-dev] CTV and ANYPREVOUT vault designs 55 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org 56 X-Mailman-Version: 2.1.15 57 Precedence: list 58 List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> 59 List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 60 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> 61 List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> 62 List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> 63 List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> 64 List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 65 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> 66 X-List-Received-Date: Sat, 15 Jan 2022 17:19:41 -0000 67 68 ------=_Part_198831_1473189489.1642267176519 69 Content-Type: text/plain; charset=UTF-8 70 Content-Transfer-Encoding: quoted-printable 71 72 Everything shared in this email was earlier posted by Michael Folkson on Bi= 73 tcoin Stackexchange (a site that allows people to close opinion based quest= 74 ions), cross posting here so that more developers could discuss and in a be= 75 tter way. I have just removed one paragraph. 76 77 At the time of writing (January 2022) there seems to be very little researc= 78 h with direct comparisons on the utility and safety of different ways to en= 79 able the construction of various vault designs. Indeed the covenant opcode = 80 TAPLEAF_UPDATE_VERIFY was only [proposed][1] to the bitcoin-dev mailing lis= 81 t in September 2021 and there are no implementations of it as yet let alone= 82 detailed analyses of how it compares to constructing vaults using SIGHASH_= 83 ANYPREVOUT or OP_CHECKTEMPLATEVERIFY. The mailing list post did suggest tha= 84 t it enables a vault design that matches a previous [vault design][2] of Br= 85 yan Bishop with additional benefits: 86 87 > It's fully recursive, allows withdrawals to vary rather than be the 88 > fixed amount L (due to not relying on pre-signed transactions), and 89 > generally seems a bit simpler to work with. 90 91 Jeremy Rubin initially [described][4] OP_CHECKOUTPUTSHASHVERIFY (which beca= 92 me OP_CHECKTEMPLATEVERIFY) as a "rudimentary, limited form of covenant whic= 93 h does not bear the same technical and social risks of prior covenant desig= 94 ns". This suggests that for vaults specifically the design space may be mor= 95 e limited using OP_CHECKTEMPLATEVERIFY. 96 97 Andrew Poelstra has blogged on how to use OP_CAT and OP_CHECKSIGFROMSTACK t= 98 o construct covenants and vaults ([1][5], [2][3]). These would enable more = 99 generalized covenants than OP_CHECKTEMPLATEVERIFY potentially increasing th= 100 e design space for vaults but with the downsides of being less efficient an= 101 d arguably riskier. There does seem to be a direct risk/reward trade-off he= 102 re when attempting to broaden the design space for vaults and it is difficu= 103 lt to assess where on the spectrum is the potential optimum given how few v= 104 ault prototypes there are let alone fully built out implementations of thos= 105 e prototypes.=C2=A0 106 107 The solitary [paper][6] that has compared building vaults using OP_CHECKTEM= 108 PLATEVERIFY and SIGHASH_ANYPREVOUT at the time of writing is **Bitcoin Cove= 109 nants: Three Ways to Control the Future**. 110 111 This paper discussed three categories of vault design: deleted key (no cons= 112 ensus changes required but inferior security model), recovered key (require= 113 s BIP 118 consensus change, superior security model) and script based (requ= 114 ires BIP 119 consensus change, superior security model). 115 116 [![Bitcoin Covenants Paper][7]][7] 117 118 It stated: 119 120 > Recovered-key and script-based covenants are mostly functionally equivale= 121 nt and 122 so the advantages that recovered-key covenants have over deleted-key covena= 123 nts also applies to Script-based covenants. If 124 either were enabled by their required soft-fork upgrade then a new domain o= 125 f practical covenant-based protocols could emerge. 126 Understanding precisely what utility is gained from such upgrades is key to= 127 their progress. 128 129 The paper concluded by stating: 130 131 > Bitcoin is a complex adaptive system with many interacting parts and 132 > there are systemic risks with every modification of bitcoin=E2=80=99s 133 > code-base and protocol. It is difficult to analyze those risks and it 134 > would be hubris to claim that there are no unknown risks being 135 > introduced. 136 137 =C2=A0 [1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Se= 138 ptember/019419.html 139 =C2=A0 [2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-Au= 140 gust/017231.html 141 =C2=A0 [3]: https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i= 142 i.html 143 =C2=A0 [4]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-Ma= 144 y/016934.html 145 =C2=A0 [5]: https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i= 146 .html 147 =C2=A0 [6]: https://arxiv.org/pdf/2006.16714.pdf 148 =C2=A0 [7]: https://i.stack.imgur.com/Udey1.png 149 150 --=20 151 Prayank 152 153 A3B1 E430 2298 178F 154 155 ------=_Part_198831_1473189489.1642267176519 156 Content-Type: text/html; charset=UTF-8 157 Content-Transfer-Encoding: quoted-printable 158 159 <html> 160 <head> 161 <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF-8= 162 "> 163 </head> 164 <body> 165 <div>Everything shared in this email was earlier posted by Michael Folkson = 166 on Bitcoin Stackexchange (a site that allows people to close opinion based = 167 questions), cross posting here so that more developers could discuss and in= 168 a better way. I have just removed one paragraph.<br></div><div dir=3D"auto= 169 "><br></div><div dir=3D"auto">At the time of writing (January 2022) there s= 170 eems to be very little research with direct comparisons on the utility and = 171 safety of different ways to enable the construction of various vault design= 172 s. Indeed the covenant opcode TAPLEAF_UPDATE_VERIFY was only [proposed][1] = 173 to the bitcoin-dev mailing list in September 2021 and there are no implemen= 174 tations of it as yet let alone detailed analyses of how it compares to cons= 175 tructing vaults using SIGHASH_ANYPREVOUT or OP_CHECKTEMPLATEVERIFY. The mai= 176 ling list post did suggest that it enables a vault design that matches a pr= 177 evious [vault design][2] of Bryan Bishop with additional benefits:<br></div= 178 ><div dir=3D"auto"><br></div><div dir=3D"auto">> It's fully recursive, a= 179 llows withdrawals to vary rather than be the<br></div><div dir=3D"auto">>= 180 ; fixed amount L (due to not relying on pre-signed transactions), and<br></= 181 div><div dir=3D"auto">> generally seems a bit simpler to work with.<br><= 182 /div><div dir=3D"auto"><br></div><div dir=3D"auto">Jeremy Rubin initially [= 183 described][4] OP_CHECKOUTPUTSHASHVERIFY (which became OP_CHECKTEMPLATEVERIF= 184 Y) as a "rudimentary, limited form of covenant which does not bear the same= 185 technical and social risks of prior covenant designs". This suggests that = 186 for vaults specifically the design space may be more limited using OP_CHECK= 187 TEMPLATEVERIFY.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">Andr= 188 ew Poelstra has blogged on how to use OP_CAT and OP_CHECKSIGFROMSTACK to co= 189 nstruct covenants and vaults ([1][5], [2][3]). These would enable more gene= 190 ralized covenants than OP_CHECKTEMPLATEVERIFY potentially increasing the de= 191 sign space for vaults but with the downsides of being less efficient and ar= 192 guably riskier. There does seem to be a direct risk/reward trade-off here w= 193 hen attempting to broaden the design space for vaults and it is difficult t= 194 o assess where on the spectrum is the potential optimum given how few vault= 195 prototypes there are let alone fully built out implementations of those pr= 196 ototypes. <br></div><div dir=3D"auto"><br></div><div dir=3D"auto">The = 197 solitary [paper][6] that has compared building vaults using OP_CHECKTEMPLAT= 198 EVERIFY and SIGHASH_ANYPREVOUT at the time of writing is **Bitcoin Covenant= 199 s: Three Ways to Control the Future**.<br></div><div dir=3D"auto"><br></div= 200 ><div dir=3D"auto">This paper discussed three categories of vault design: d= 201 eleted key (no consensus changes required but inferior security model), rec= 202 overed key (requires BIP 118 consensus change, superior security model) and= 203 script based (requires BIP 119 consensus change, superior security model).= 204 <br></div><div dir=3D"auto"><br></div><div dir=3D"auto">[![Bitcoin Covenant= 205 s Paper][7]][7]<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">It s= 206 tated:<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">> Recovere= 207 d-key and script-based covenants are mostly functionally equivalent and<br>= 208 </div><div dir=3D"auto">so the advantages that recovered-key covenants have= 209 over deleted-key covenants also applies to Script-based covenants. If<br><= 210 /div><div dir=3D"auto">either were enabled by their required soft-fork upgr= 211 ade then a new domain of practical covenant-based protocols could emerge.<b= 212 r></div><div dir=3D"auto">Understanding precisely what utility is gained fr= 213 om such upgrades is key to their progress.<br></div><div dir=3D"auto"><br><= 214 /div><div dir=3D"auto">The paper concluded by stating:<br></div><div dir=3D= 215 "auto"><br></div><div dir=3D"auto">> Bitcoin is a complex adaptive syste= 216 m with many interacting parts and<br></div><div dir=3D"auto">> there are= 217 systemic risks with every modification of bitcoin=E2=80=99s<br></div><div = 218 dir=3D"auto">> code-base and protocol. It is difficult to analyze those = 219 risks and it<br></div><div dir=3D"auto">> would be hubris to claim that = 220 there are no unknown risks being<br></div><div dir=3D"auto">> introduced= 221 .<br></div><div dir=3D"auto"><br></div><div dir=3D"auto"> [1]: <a hre= 222 f=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September= 223 /019419.html">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-= 224 September/019419.html</a><br></div><div dir=3D"auto"> [2]: <a href=3D= 225 "https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017231= 226 .html">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/= 227 017231.html</a><br></div><div dir=3D"auto"> [3]: <a href=3D"https://w= 228 ww.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html">https://www.w= 229 psoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html</a><br></div><div = 230 dir=3D"auto"> [4]: <a href=3D"https://lists.linuxfoundation.org/piper= 231 mail/bitcoin-dev/2019-May/016934.html">https://lists.linuxfoundation.org/pi= 232 permail/bitcoin-dev/2019-May/016934.html</a><br></div><div dir=3D"auto">&nb= 233 sp; [5]: <a href=3D"https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-= 234 tricks-i.html">https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-trick= 235 s-i.html</a><br></div><div dir=3D"auto"> [6]: <a href=3D"https://arxi= 236 v.org/pdf/2006.16714.pdf">https://arxiv.org/pdf/2006.16714.pdf</a><br></div= 237 ><div dir=3D"auto"> [7]: <a href=3D"https://i.stack.imgur.com/Udey1.p= 238 ng">https://i.stack.imgur.com/Udey1.png</a><br></div><div><br></div><div>--= 239 <br></div><div>Prayank<br></div><div><br></div><div dir=3D"auto">A3B1 E430= 240 2298 178F<br></div> </body> 241 </html> 242 243 ------=_Part_198831_1473189489.1642267176519-- 244