e73a896416e44628e943fa8f4625cf4ddc23e1
1 Return-Path: <j@rubin.io> 2 Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) 3 by lists.linuxfoundation.org (Postfix) with ESMTP id 3B115C002D 4 for <bitcoin-dev@lists.linuxfoundation.org>; 5 Tue, 26 Apr 2022 20:17:45 +0000 (UTC) 6 Received: from localhost (localhost [127.0.0.1]) 7 by smtp4.osuosl.org (Postfix) with ESMTP id 1A08C4191A 8 for <bitcoin-dev@lists.linuxfoundation.org>; 9 Tue, 26 Apr 2022 20:17:45 +0000 (UTC) 10 X-Virus-Scanned: amavisd-new at osuosl.org 11 X-Spam-Flag: NO 12 X-Spam-Score: 0.076 13 X-Spam-Level: 14 X-Spam-Status: No, score=0.076 tagged_above=-999 required=5 15 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, PDS_OTHER_BAD_TLD=1.975, 16 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 17 Received: from smtp4.osuosl.org ([127.0.0.1]) 18 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) 19 with ESMTP id NgFQzq-OO-Tu 20 for <bitcoin-dev@lists.linuxfoundation.org>; 21 Tue, 26 Apr 2022 20:17:43 +0000 (UTC) 22 X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 23 Received: from mslow1.mail.gandi.net (mslow1.mail.gandi.net [217.70.178.240]) 24 by smtp4.osuosl.org (Postfix) with ESMTPS id 39F6D41911 25 for <bitcoin-dev@lists.linuxfoundation.org>; 26 Tue, 26 Apr 2022 20:17:42 +0000 (UTC) 27 Received: from relay1-d.mail.gandi.net (unknown [IPv6:2001:4b98:dc4:8::221]) 28 by mslow1.mail.gandi.net (Postfix) with ESMTP id 14D5FCF602 29 for <bitcoin-dev@lists.linuxfoundation.org>; 30 Tue, 26 Apr 2022 20:13:45 +0000 (UTC) 31 Received: (Authenticated sender: j@rubin.io) 32 by mail.gandi.net (Postfix) with ESMTPSA id 61824240002 33 for <bitcoin-dev@lists.linuxfoundation.org>; 34 Tue, 26 Apr 2022 20:13:39 +0000 (UTC) 35 Received: by mail-lj1-f169.google.com with SMTP id l19so10838747ljb.7 36 for <bitcoin-dev@lists.linuxfoundation.org>; 37 Tue, 26 Apr 2022 13:13:39 -0700 (PDT) 38 X-Gm-Message-State: AOAM532/3rg3WQ0dYXgwkaAP9QXsk9lGbybtax+s2YOj7OIaefIOcm1o 39 o+sGxXe67T1vLzXCsrbtK4Gkr1q0I9TsTmnppuU= 40 X-Google-Smtp-Source: ABdhPJz6hDvZRfvH5IISm0vn0JWGaHA52xk/0ikErCwVclcSPLecbyhdqcAXNYDGq+g3wa8klBwu1RW1B1eOJ9DsRfw= 41 X-Received: by 2002:a2e:a545:0:b0:24d:c472:9969 with SMTP id 42 e5-20020a2ea545000000b0024dc4729969mr15022473ljn.376.1651004018507; Tue, 26 43 Apr 2022 13:13:38 -0700 (PDT) 44 MIME-Version: 1.0 45 References: <p3P0m2_aNXd-4oYhFjCKJyI8zQXahmZed6bv7lnj9M9HbP9gMqMtJr-pP7XRAPs-rn_fJuGu1cv9ero5i8f0cvyZrMXYPzPx17CxJ2ZSvRk=@protonmail.com> 46 In-Reply-To: <p3P0m2_aNXd-4oYhFjCKJyI8zQXahmZed6bv7lnj9M9HbP9gMqMtJr-pP7XRAPs-rn_fJuGu1cv9ero5i8f0cvyZrMXYPzPx17CxJ2ZSvRk=@protonmail.com> 47 From: Jeremy Rubin <j@rubin.io> 48 Date: Tue, 26 Apr 2022 13:13:26 -0700 49 X-Gmail-Original-Message-ID: <CAD5xwhi6DYVm3sONub0x4s=Ef0TupA4j4KxY616RnacXr1GsLA@mail.gmail.com> 50 Message-ID: <CAD5xwhi6DYVm3sONub0x4s=Ef0TupA4j4KxY616RnacXr1GsLA@mail.gmail.com> 51 To: darosior <darosior@protonmail.com>, 52 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> 53 Content-Type: multipart/alternative; boundary="0000000000000bc41805dd945442" 54 X-Mailman-Approved-At: Tue, 26 Apr 2022 20:21:40 +0000 55 Subject: Re: [bitcoin-dev] ANYPREVOUT in place of CTV 56 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org 57 X-Mailman-Version: 2.1.15 58 Precedence: list 59 List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> 60 List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 61 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> 62 List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> 63 List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> 64 List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> 65 List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 66 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> 67 X-List-Received-Date: Tue, 26 Apr 2022 20:17:45 -0000 68 69 --0000000000000bc41805dd945442 70 Content-Type: text/plain; charset="UTF-8" 71 72 I can't find all of my earlier references around this, I thought I made a 73 thread on it, but as a reminder, my thoughts for mild tweaks to APO that 74 make it a bit less hacky are as follows: 75 76 - Remove OP_1 key punning and replace it with OP_GENERATOR and 77 OP_INTERNALKEY (maybe OP_EXTERNALKEY too?). The key punning is useful 78 generically, because I may want to reuse the internal key in conjunction 79 with a script path in some circumstances. 80 - Add an additional sequence field that is specific to a signature with no 81 other consensus meaning, so APO can be used with absolute timelocks. For 82 example, this makes it impossible for more than one ratchet to be 83 aggregated within a single transaction under any circumstance if their 84 sequences differ (not sure this is a good example, but an example 85 nonetheless). 86 - Replace tagged keys for APO with either a Checksig2 or a separate feature 87 flag that enables or disables APO behavior so that we can have programmatic 88 control over if APO is allowed for a given key (e..g., OP_IF <N> CSV DROP 89 CHECKSIG2 OP_ELSE CHECKSIG OP_ENDIF enables APO to be turned on after a 90 certain time, perhaps for a pre-approved backup transaction). 91 92 Overall, this would make eltoo ratchets look something like this: 93 94 <sig> <seq> OP_1 OP_INTERNALKEY OP_CHECKSIG2VERIFY <N> OP_GREATERTHAN 95 96 where checksig2 leaves seq on the stack which can be used to enforce the 97 ratchet. 98 99 and covenants like: 100 101 <sig> OP_1 OP_1 OP_GENERATOR OP_CHECKSIG2VERIFY 102 103 104 105 106 107 108 109 On Fri, Apr 22, 2022 at 4:23 AM darosior via bitcoin-dev < 110 bitcoin-dev@lists.linuxfoundation.org> wrote: 111 112 > I would like to know people's sentiment about doing (a very slightly 113 > tweaked version of) BIP118 in place of 114 > (or before doing) BIP119. 115 > 116 > SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for 117 > over 6 years. It presents proven and 118 > implemented usecases, that are demanded and (please someone correct me if 119 > i'm wrong) more widely accepted than 120 > CTV's. 121 > 122 > SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made 123 > optional [0], can emulate CTV just fine. 124 > Sure then you can't have bare or Segwit v0 CTV, and it's a bit more 125 > expensive to use. But we can consider CTV 126 > an optimization of APO-AS covenants. 127 > 128 > CTV advocates have been presenting vaults as the flagship usecase. 129 > Although as someone who've been trying to 130 > implement practical vaults for the past 2 years i doubt CTV is necessary 131 > nor sufficient for this (but still 132 > useful!), using APO-AS covers it. And it's not a couple dozen more virtual 133 > bytes that are going to matter for 134 > a potential vault user. 135 > 136 > If after some time all of us who are currently dubious about CTV's stated 137 > usecases are proven wrong by onchain 138 > usage of a less efficient construction to achieve the same goal, we could 139 > roll-out CTV as an optimization. In 140 > the meantime others will have been able to deploy new applications 141 > leveraging ANYPREVOUT (Eltoo, blind 142 > statechains, etc..[1]). 143 > 144 > 145 > Given the interest in, and demand for, both simple covenants and better 146 > offchain protocols it seems to me that 147 > BIP118 is a soft fork candidate that could benefit more (if not most of) 148 > Bitcoin users. 149 > Actually i'd also be interested in knowing if people would oppose the 150 > APO-AS part of BIP118, since it enables 151 > CTV's features, for the same reason they'd oppose BIP119. 152 > 153 > 154 > [0] That is, to not commit to the other inputs of the transaction (via 155 > `sha_sequences` and maybe also 156 > `sha_amounts`). Cf 157 > https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message 158 > . 159 > 160 > [1] https://anyprevout.xyz/ "Use Cases" section 161 > _______________________________________________ 162 > bitcoin-dev mailing list 163 > bitcoin-dev@lists.linuxfoundation.org 164 > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev 165 > 166 167 --0000000000000bc41805dd945442 168 Content-Type: text/html; charset="UTF-8" 169 Content-Transfer-Encoding: quoted-printable 170 171 <div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he= 172 lvetica,sans-serif;font-size:small;color:#000000">I can't find all of m= 173 y earlier references around this, I thought I made a thread on it, but as a= 174 reminder, my thoughts for mild tweaks to APO that make it a bit less hacky= 175 are as follows:</div><div class=3D"gmail_default" style=3D"font-family:ari= 176 al,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class= 177 =3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz= 178 e:small;color:#000000">- Remove OP_1 key punning and replace it with OP_GEN= 179 ERATOR and OP_INTERNALKEY (maybe OP_EXTERNALKEY too?). The key punning is u= 180 seful generically, because I may want to reuse the internal key in conjunct= 181 ion with a script path in some circumstances.</div><div class=3D"gmail_defa= 182 ult" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:= 183 #000000">- Add an additional sequence field that is specific to a signature= 184 with no other consensus meaning, so APO can be used with absolute timelock= 185 s. For example, this makes it impossible for more than one ratchet to be ag= 186 gregated within a single transaction under any circumstance if their sequen= 187 ces differ (not sure this is a good example, but an example nonetheless).</= 188 div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-= 189 serif;font-size:small;color:#000000">- Replace tagged keys for APO with eit= 190 her a Checksig2 or a separate feature flag that enables or disables APO beh= 191 avior so that we can have programmatic control over if APO is allowed for a= 192 given key (e..g., OP_IF <N> CSV DROP CHECKSIG2 OP_ELSE CHECKSIG OP_E= 193 NDIF enables APO to be turned on after a certain time, perhaps for a pre-ap= 194 proved backup transaction).</div><div class=3D"gmail_default" style=3D"font= 195 -family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div= 196 ><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-ser= 197 if;font-size:small;color:#000000">Overall, this would make eltoo ratchets l= 198 ook something like this:</div><div class=3D"gmail_default" style=3D"font-fa= 199 mily:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><d= 200 iv class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;= 201 font-size:small;color:#000000"><sig> <seq> OP_1 OP_INTERNALKEY = 202 OP_CHECKSIG2VERIFY <N> OP_GREATERTHAN</div><div class=3D"gmail_defaul= 203 t" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#0= 204 00000"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,he= 205 lvetica,sans-serif;font-size:small;color:#000000">where checksig2 leaves se= 206 q on the stack which can be used to enforce the ratchet.</div><div class=3D= 207 "gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:s= 208 mall;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font-fa= 209 mily:arial,helvetica,sans-serif;font-size:small;color:#000000">and covenant= 210 s like:</div><div class=3D"gmail_default" style=3D"font-family:arial,helvet= 211 ica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail= 212 _default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c= 213 olor:#000000"><sig> OP_1 OP_1 OP_GENERATOR OP_CHECKSIG2VERIFY</div><d= 214 iv class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;= 215 font-size:small;color:#000000"><br></div><div class=3D"gmail_default" style= 216 =3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><= 217 br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,= 218 sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_def= 219 ault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color= 220 :#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:arial= 221 ,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class= 222 =3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz= 223 e:small;color:#000000"><br></div></div><br><div class=3D"gmail_quote"><div = 224 dir=3D"ltr" class=3D"gmail_attr">On Fri, Apr 22, 2022 at 4:23 AM darosior v= 225 ia bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org"= 226 >bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote = 227 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1= 228 px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:= 229 1ex">I would like to know people's sentiment about doing (a very slight= 230 ly tweaked version of) BIP118 in place of<br> 231 (or before doing) BIP119.<br> 232 <br> 233 SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for ove= 234 r 6 years. It presents proven and<br> 235 implemented usecases, that are demanded and (please someone correct me if i= 236 'm wrong) more widely accepted than<br> 237 CTV's.<br> 238 <br> 239 SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is m= 240 ade optional [0], can emulate CTV just fine.<br> 241 Sure then you can't have bare or Segwit v0 CTV, and it's a bit more= 242 expensive to use. But we can consider CTV<br> 243 an optimization of APO-AS covenants.<br> 244 <br> 245 CTV advocates have been presenting vaults as the flagship usecase. Although= 246 as someone who've been trying to<br> 247 implement practical vaults for the past 2 years i doubt CTV is necessary no= 248 r sufficient for this (but still<br> 249 useful!), using APO-AS covers it. And it's not a couple dozen more virt= 250 ual bytes that are going to matter for<br> 251 a potential vault user.<br> 252 <br> 253 If after some time all of us who are currently dubious about CTV's stat= 254 ed usecases are proven wrong by onchain<br> 255 usage of a less efficient construction to achieve the same goal, we could r= 256 oll-out CTV as an optimization.=C2=A0 In<br> 257 the meantime others will have been able to deploy new applications leveragi= 258 ng ANYPREVOUT (Eltoo, blind<br> 259 statechains, etc..[1]).<br> 260 <br> 261 <br> 262 Given the interest in, and demand for, both simple covenants and better off= 263 chain protocols it seems to me that<br> 264 BIP118 is a soft fork candidate that could benefit more (if not most of) Bi= 265 tcoin users.<br> 266 Actually i'd also be interested in knowing if people would oppose the A= 267 PO-AS part of BIP118, since it enables<br> 268 CTV's features, for the same reason they'd oppose BIP119.<br> 269 <br> 270 <br> 271 [0] That is, to not commit to the other inputs of the transaction (via `sha= 272 _sequences` and maybe also<br> 273 `sha_amounts`). Cf <a href=3D"https://github.com/bitcoin/bips/blob/master/b= 274 ip-0118.mediawiki#signature-message" rel=3D"noreferrer" target=3D"_blank">h= 275 ttps://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-mes= 276 sage</a>.<br> 277 <br> 278 [1] <a href=3D"https://anyprevout.xyz/" rel=3D"noreferrer" target=3D"_blank= 279 ">https://anyprevout.xyz/</a> "Use Cases" section<br> 280 _______________________________________________<br> 281 bitcoin-dev mailing list<br> 282 <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= 283 bitcoin-dev@lists.linuxfoundation.org</a><br> 284 <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = 285 rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= 286 man/listinfo/bitcoin-dev</a><br> 287 </blockquote></div> 288 289 --0000000000000bc41805dd945442-- 290