diff options
| author | Alex Schoof <alex.schoof@gmail.com> | 2022-01-18 19:37:02 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-01-19 00:37:19 +0000 |
| commit | 21ad7a7fd52c7fd8e763cc177877a9eb986d2363 (patch) | |
| tree | 7b9290d3594dd2e6d9431fc8f06b856afd5fc657 | |
| parent | 04af7e78dc9fb62d108cb4db377c528cc224f426 (diff) | |
| download | pi-bitcoindev-21ad7a7fd52c7fd8e763cc177877a9eb986d2363.tar.gz pi-bitcoindev-21ad7a7fd52c7fd8e763cc177877a9eb986d2363.zip | |
Re: [bitcoin-dev] CTV BIP review
| -rw-r--r-- | 86/569c1d30f089518cc0a7f021d378a17507106b | 618 |
1 files changed, 618 insertions, 0 deletions
diff --git a/86/569c1d30f089518cc0a7f021d378a17507106b b/86/569c1d30f089518cc0a7f021d378a17507106b new file mode 100644 index 000000000..884ba1aac --- /dev/null +++ b/86/569c1d30f089518cc0a7f021d378a17507106b @@ -0,0 +1,618 @@ +Return-Path: <alex.schoof@gmail.com> +Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 13DE7C002F + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 19 Jan 2022 00:37:19 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp1.osuosl.org (Postfix) with ESMTP id E304A813A8 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 19 Jan 2022 00:37:18 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -2.098 +X-Spam-Level: +X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, + HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, + SPF_PASS=-0.001] autolearn=ham autolearn_force=no +Authentication-Results: smtp1.osuosl.org (amavisd-new); + dkim=pass (2048-bit key) header.d=gmail.com +Received: from smtp1.osuosl.org ([127.0.0.1]) + by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id uB2eIqGchhQk + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 19 Jan 2022 00:37:17 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com + [IPv6:2a00:1450:4864:20::12d]) + by smtp1.osuosl.org (Postfix) with ESMTPS id E46EC8138E + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 19 Jan 2022 00:37:16 +0000 (UTC) +Received: by mail-lf1-x12d.google.com with SMTP id o15so2166865lfo.11 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 18 Jan 2022 16:37:16 -0800 (PST) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; + h=mime-version:references:in-reply-to:from:date:message-id:subject:to + :cc; bh=QAtr92vzu0dusrzPqvPVGx2gT0ILl7752OaCzqoUr8s=; + b=P7Y8owySGFpPxJiyS6vuUc8kFKUPJ8sk5/pxCCkHI1NW8puzBEQSSDwb9NIRquR+WP + P+uFKJks3CVQwkqcrg6y6bG0r+zUOeHPc6qFzLfDErNUDhdOdkkmj+Qnr4qBbCgfV6b5 + 2JELnqvOKVuguMqbgfkQdUGQFLOUf/0UUmLFi+Vvw/2Gz7bEQkZVnV3zch/G1AIcrz4h + 3pvIEcicuLQcOO4qz5RNdrzEgA1AgRxGwVT591aSqsKbQkToLs85sFH6Cd3hs/RUZG+3 + xZTTKM/jcOF7JivoWcxYrofmMzxMphxNvxre3aTP7XQO/+P5bj9XrpKkMa+J/Imds7k8 + 9cvA== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20210112; + h=x-gm-message-state:mime-version:references:in-reply-to:from:date + :message-id:subject:to:cc; + bh=QAtr92vzu0dusrzPqvPVGx2gT0ILl7752OaCzqoUr8s=; + b=61cT0rTCSxmtdJYpFdEzOafzZ8ns2t1b/eSpkmw3dfU2LQH1J55IkVWE6nnKP0wxY6 + 8NT4AQGvxfd4xgfVSalKAARGneyZler0qKr6xSh0M7r1Vt5+jFvI5HXCqM3FvQTaXPTV + ftrL+EBR4rc6LlgAK/E/KgIqZ9qUCn4dRMqt1F5E8APJ19D7li0IwjTv30TENHL7iiq8 + mMLmnOxcEyJKQaRUyKqB6CvgqKhxNR2I8SaRbJv2g/XcIVacyGJkWBMmeMUdpYQtJsDr + EqhsWe/nC62kCvlaj3SGSg+KQkoAQfjO0VaOVOD3OiqluhHblnjdGK3mqMXNRlstvNoO + IKlQ== +X-Gm-Message-State: AOAM533hEeze4Y2NF9ynLUfV9cHWtAT4MiblpVEOmqju5hS7NP27oruM + QqWbGrp3RAnjjzr7u8I7ZohC+eL2N7LUXFJ82ZY= +X-Google-Smtp-Source: ABdhPJwOxQSiJ8JK8avxwviNxByOJpM5LaA3sS+cnMt3vCPJkrFHOjtqFjnAaiUfIc5/Sorzo52d7w8G03+9BDXzaj4= +X-Received: by 2002:a2e:bf13:: with SMTP id c19mr1688843ljr.104.1642552634799; + Tue, 18 Jan 2022 16:37:14 -0800 (PST) +MIME-Version: 1.0 +References: <202201182119.02687.luke@dashjr.org> + <CAD5xwhh3d1=KXEJOPVuYm3UqNKovrojqJS-c6r6ficsKf6S_7g@mail.gmail.com> +In-Reply-To: <CAD5xwhh3d1=KXEJOPVuYm3UqNKovrojqJS-c6r6ficsKf6S_7g@mail.gmail.com> +From: Alex Schoof <alex.schoof@gmail.com> +Date: Tue, 18 Jan 2022 19:37:02 -0500 +Message-ID: <CA+2b5C31jcDZaeov5_2kmcfRbMCr2nmdJd0UphGR_2PaGB3y5Q@mail.gmail.com> +To: Jeremy <jlrubin@mit.edu>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="000000000000527c4005d5e496c1" +X-Mailman-Approved-At: Wed, 19 Jan 2022 09:11:58 +0000 +Subject: Re: [bitcoin-dev] CTV BIP review +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: Wed, 19 Jan 2022 00:37:19 -0000 + +--000000000000527c4005d5e496c1 +Content-Type: text/plain; charset="UTF-8" + +Hey Jeremy, + +> On the topic of drafting BIPs for specific use cases, I agree that would +be valuable and can consider it. +> However, I'm a bit skeptical of that approach overall as I don't +necessarily think that the applications *must be* standard, and I view BIPs +as primarily for standardization whereas part of the flexibility of +CTV/Sapio allows users to figure out how they want to use it. + +Electronic components (think an integrated circuit or a capacitor) usually +have both a "data sheet" and a set of "application notes". The data sheet +is like a spec or the formal documentation: how the thing works (or is +intended to work), precise dimensions and tolerances, etc. On the other +hand, the Application Notes are either a separate document or an appendix +to the data sheet with specific details about using that component in a +specific application: things like schematics for an example implementation, +things to watch out for (edge cases or unexpected application-specific +behavior, etc.). I appreciate the balance you're trying to strike between +having the BIP for CTV have enough details about how you think it might be +used and having it exclusively be a spec to help drive standardization. +Maybe the solution here is to have some explicit application notes that +have enough details to give people a sense of how these uses could be built +out, but still have it be clear that they are a use of, not a part of CTV +itself by having it either in a linked document or an appendix or +something. + +Just a suggestion. + +Cheers, + +Alex + +On Tue, Jan 18, 2022 at 6:54 PM Jeremy via bitcoin-dev < +bitcoin-dev@lists.linuxfoundation.org> wrote: + +> Thanks for the detailed review. +> +> I'll withhold comment around activation logic and leave that for others to +> discuss. +> +> w.r.t. the language cleanups I'll make a PR that (I hope) clears up the +> small nits later today or tomorrow. Some of it's kind of annoying because +> the legal definition of covenant is "A formal agreement or promise, +> usually included in a contract or deed, to do or not do a particular act; a +> compact or stipulation made in writing or by parol." so I do think things +> like CLTV/CSV are covenants since it's a binding promise to not spend +> before a certain time... it might be out of scope for the BIP to fully +> define these terms because it doesn't really matter what a covenant could +> be as much as it matters what CTV is specifically. +> +> On the topic of drafting BIPs for specific use cases, I agree that would +> be valuable and can consider it. +> +> However, I'm a bit skeptical of that approach overall as I don't +> necessarily think that the applications *must be* standard, and I view BIPs +> as primarily for standardization whereas part of the flexibility of +> CTV/Sapio allows users to figure out how they want to use it. +> +> E.g., we do not yet have a BIP for MuSig or even Multisig in Taproot, +> although there are some papers and example implementations but nothing +> formal yet +> https://bitcoin.stackexchange.com/questions/111666/support-for-taproot-multisig-descriptors). +> Perhaps this is an opportunity for CTV to lead on the amount of formal +> application designs available before 'release'. +> +> As a starting point, maybe you could review some of the application +> focused posts in rubin.io/advent21 and let me know where they seem +> deficient? +> +> Also a BIP describing how to build something like Sapio (and less so Sapio +> itself, since it's still early days for that) might help for folks to be +> able to think through how to compile to CTV contracts? But again, I'm +> skeptical of the value of a BIP v.s. the documentation and examples +> available in the code and https://learn.sapio-lang.org. +> +> I think it's an interesting discussion too because as we've just seen the +> LN ecosystem start the BLIP standards, would an example of non-interactive +> channels be best written up as a BIP, a BLIP, or a descriptive blog/mailing +> list post? +> +> -- +> @JeremyRubin <https://twitter.com/JeremyRubin> +> <https://twitter.com/JeremyRubin> +> +> +> On Tue, Jan 18, 2022 at 1:19 PM Luke Dashjr via bitcoin-dev < +> bitcoin-dev@lists.linuxfoundation.org> wrote: +> +>> tl;dr: I don't think CTV is ready yet (but probably close), and in any +>> case +>> definitely not worth reviving BIP 9 with its known flaws and +>> vulnerability. +>> +>> My review here is based solely on the BIP, with no outside context (aside +>> from +>> current consensus rules, of course). In particular, I have _not_ looked +>> at +>> the CTV code proposed for Bitcoin Core yet. +>> +>> >Covenants are restrictions on how a coin may be spent beyond key +>> ownership. +>> +>> nit: Poorly phrased. Even simple scripts can do that already. +>> +>> >A few examples are described below, which should be the subject of +>> future +>> non-consensus standardization efforts. +>> +>> I would ideally like to see fully implemented BIPs for at least one of +>> these +>> (preferably the claimed CoinJoin improvements) before we move toward +>> activation. +>> +>> >Congestion Controlled Transactions +>> +>> I think this use case hasn't been fully thought through yet. It seems +>> like it +>> would be desirable for this purpose, to allow any of the recipients to +>> claim +>> their portion of the payment without footing the fee for every other +>> payment +>> included in the batch. This is still a covenant-type solution, but one +>> that +>> BIP 119 cannot support as-is. +>> +>> (I realise this may be a known and accepted limitation, but I think it +>> should +>> be addressed in the BIP) +>> +>> >Payment Channels +>> +>> Why batch mere channel creation? Seems like the spending transaction +>> should +>> really be the channel closing. +>> +>> >CHECKTEMPLATEVERIFY makes it much easier to set up trustless CoinJoins +>> than +>> previously because participants agree on a single output which pays all +>> participants, which will be lower fee than before. +>> +>> I don't see how. They still have to agree in advance on the outputs, and +>> the +>> total fees will logically be higher than not using CTV...? +>> +>> >Further Each participant doesn't need to know the totality of the +>> outputs +>> committed to by that output, they only have to verify their own sub-tree +>> will +>> pay them. +>> +>> I don't see any way to do this with the provided implementation. +>> +>> >Deployment could be done via BIP 9 VersionBits deployed through Speedy +>> Trial. +>> +>> Hard NACK on this. BIP 9 at this point represents developers attempting +>> to +>> disregard and impose their will over community consensus, as well as an +>> attempt to force a miner veto backdoor/vulnerability on deployment. It +>> should +>> never be used again. +>> +>> Speedy Trial implemented with BIP 8 made sense* as a possible neutral +>> compromise between LOT=True and LOT=False (which could be deployed prior +>> to +>> or in parallel), but using BIP 9 would destroy this. +>> +>> As with Taproot, any future deployments should use BIP 8 again, until a +>> better +>> solution is developed. Reverting back to a known flawed and vulnerable +>> activation method should not be done, and it would be better not to +>> deploy +>> CTV at all at such an expense. +>> +>> The fact that certain developers attempted to deploy a BIP 9 alternative +>> activation for Taproot against community consensus, and that even managed +>> to +>> get released as "Bitcoin Core", makes it all the more important that the +>> community firmly rejects any further action to force this regression. +>> +>> * it is my opinion a BIP 8 ST would be an okay compromise under those +>> circumstances; others do disagree that ST is acceptable at all +>> +>> > This ensures that for a given known input, the TXIDs can also be known +>> ahead +>> of time. Otherwise, CHECKTEMPLATEVERIFY would not be usable for Batched +>> Channel Creation constructions as the redemption TXID could be malleated +>> and +>> pre-signed transactions invalidated, unless the channels are built using +>> an +>> Eltoo-like protocol. +>> +>> Why is it a problem for them to use an Eltoo-like protocol? +>> +>> Why not just commit to the txid itself if that's the goal? +>> +>> >P2SH is incompatible with CHECKTEMPLATEVERIFY +>> +>> Maybe the CTV opcode should only be defined/enforced within witness +>> scripts? +>> +>> >nLockTime should generally be fixed to 0 (in the case of a payment tree, +>> only +>> the *first* lock time is needed to prevent fee-sniping the root) +>> +>> Your "Congestion Controlled Transactions" example would only make sense +>> with +>> the spending transaction much later than the "root", and so could benefit +>> from fee sniping malleability. (In fact, in that example, it would be +>> better +>> not to commit to locktime at all.) +>> +>> >In the CHECKTEMPLATEVERIFY approach, the covenants are severely +>> restricted to +>> simple templates. The structure of CHECKTEMPLATEVERIFY template is such +>> that +>> the outputs must be known exactly at the time of construction. Based on a +>> destructuring argument, it is only possible to create templates which +>> expand +>> in a finite number of steps. +>> +>> It's not clear to me that this holds if OP_CAT or OP_SHA256STREAM get +>> added. +>> +>> >For example, a exchange's hot wallet might use an address which can +>> automatically be moved to a cold storage address after a relative timeout. +>> +>> Wouldn't it make more sense to just have a UTXO both cold+hot can spend, +>> then +>> throw away the hot key? +>> +>> >In contrast to previous forks, OP_CHECKTEMPLATEVERIFY will not make +>> scripts +>> valid for policy until the new rule is active. +>> +>> Policy isn't validity, and cannot be dictated by BIPs (or +>> anyone/anything, for +>> that matter). +>> +>> Luke +>> _______________________________________________ +>> bitcoin-dev mailing list +>> bitcoin-dev@lists.linuxfoundation.org +>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +>> +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> + + +-- + + +Alex Schoof + +--000000000000527c4005d5e496c1 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">Hey Jeremy,=C2=A0<div><br></div><div>> On the topic of = +drafting BIPs for specific use cases, I agree that would be valuable and ca= +n consider it.</div><div class=3D"gmail_default">> However, I'm a bi= +t skeptical of that approach overall as I don't necessarily think that = +the applications *must be* standard, and I view BIPs as primarily for stand= +ardization whereas part of the flexibility of CTV/Sapio allows users to fig= +ure out how they want to use it.</div><div class=3D"gmail_default"><br></di= +v><div class=3D"gmail_default">Electronic components (think an integrated c= +ircuit or a capacitor) usually have both a "data sheet" and a set= + of "application notes". The data sheet is like a spec or the for= +mal documentation: how the thing works (or is intended to work), precise=C2= +=A0dimensions and tolerances, etc. On the other hand, the Application Notes= + are either a separate=C2=A0document or an appendix to the data sheet with = +specific details=C2=A0about using that component in a specific application:= + things like schematics=C2=A0for an example implementation, things to watch= + out for (edge cases or unexpected application-specific behavior, etc.). I = +appreciate the balance you're trying to strike between having the BIP f= +or CTV have enough details about how you think it might be used and having = +it exclusively be a spec to help drive standardization. Maybe the solution = +here is to have some explicit application notes that have enough details to= + give people a sense of how these uses could be built out, but still have i= +t be clear that they are a use of, not a part of CTV itself by having it ei= +ther in a linked document or an appendix or something.=C2=A0</div><div clas= +s=3D"gmail_default"><br></div><div class=3D"gmail_default">Just a suggestio= +n.=C2=A0</div><div class=3D"gmail_default"><br></div><div class=3D"gmail_de= +fault">Cheers,</div><div class=3D"gmail_default"><br></div><div class=3D"gm= +ail_default">Alex</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr= +" class=3D"gmail_attr">On Tue, Jan 18, 2022 at 6:54 PM Jeremy via bitcoin-d= +ev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev= +@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote class=3D"gma= +il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le= +ft-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div di= +r=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,helvetica= +,sans-serif;font-size:small;color:rgb(0,0,0)">Thanks for the detailed revie= +w.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,s= +ans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_d= +efault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;col= +or:rgb(0,0,0)">I'll withhold=C2=A0comment around activation logic and l= +eave that for others to discuss.</div><div class=3D"gmail_default" style=3D= +"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><= +br></div><div class=3D"gmail_default"><font color=3D"#000000" face=3D"arial= +, helvetica, sans-serif">w.r.t. the language cleanups I'll make a PR th= +at (I hope) clears up the small nits later today or tomorrow. Some of it= +9;s kind of annoying because the legal definition of covena</font>nt is &qu= +ot;A formal agreement or promise, usually included in a contract or deed, t= +o do or not do a particular act; a compact or stipulation made in writing o= +r by parol." so I do think things like CLTV/CSV are covenants since it= +'s a binding promise to not spend before a certain time... it might be = +out of scope for the BIP to fully define these terms because it doesn't= + really matter what a covenant could be as much as it matters what CTV is s= +pecifically.</div><div class=3D"gmail_default"><br></div><div class=3D"gmai= +l_default">On the topic of drafting BIPs for specific use cases, I agree th= +at would be valuable and can consider it.</div><div class=3D"gmail_default"= +><br></div><div class=3D"gmail_default">However, I'm a bit skeptical of= + that approach overall as I don't necessarily think that the applicatio= +ns *must be* standard, and I view BIPs as primarily for standardization whe= +reas part of the flexibility of CTV/Sapio allows users to figure out how th= +ey want to use it.</div><div class=3D"gmail_default"><br></div><div class= +=3D"gmail_default">E.g., we do not yet have a BIP for MuSig or even Multisi= +g in Taproot, although there are some papers and example implementations bu= +t nothing formal yet =C2=A0<a href=3D"https://bitcoin.stackexchange.com/que= +stions/111666/support-for-taproot-multisig-descriptors" target=3D"_blank">h= +ttps://bitcoin.stackexchange.com/questions/111666/support-for-taproot-multi= +sig-descriptors</a>). Perhaps this is an opportunity for CTV to lead on the= + amount of formal application designs available before 'release'.</= +div><div class=3D"gmail_default"><br></div><div class=3D"gmail_default">As = +a starting point, maybe you could review some of the application focused po= +sts in <a href=3D"http://rubin.io/advent21" target=3D"_blank">rubin.io/adve= +nt21</a> and let me know where they seem deficient?</div><div class=3D"gmai= +l_default"><br></div><div class=3D"gmail_default">Also a BIP describing how= + to build something like Sapio (and less so Sapio itself, since it's st= +ill early days for that) might help for folks to be able to think through h= +ow to compile to CTV contracts? But again, I'm skeptical of the value o= +f a BIP v.s. the documentation and examples available in the code and <a hr= +ef=3D"https://learn.sapio-lang.org" target=3D"_blank">https://learn.sapio-l= +ang.org</a>.</div><div class=3D"gmail_default"><br></div><div class=3D"gmai= +l_default">I think it's an interesting discussion too because as we'= +;ve just seen the LN ecosystem start the BLIP standards, would an example o= +f non-interactive channels be best written up as a BIP, a BLIP, or a descri= +ptive blog/mailing list post?</div><div class=3D"gmail_default" style=3D"fo= +nt-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br>= +</div><div><div dir=3D"ltr"><div dir=3D"ltr">--<br><a href=3D"https://twitt= +er.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a href=3D"https://tw= +itter.com/JeremyRubin" target=3D"_blank"></a></div></div></div><br></div><b= +r><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, = +Jan 18, 2022 at 1:19 PM Luke Dashjr via bitcoin-dev <<a href=3D"mailto:b= +itcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.l= +inuxfoundation.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote= +" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style= +:solid;border-left-color:rgb(204,204,204);padding-left:1ex">tl;dr: I don= +9;t think CTV is ready yet (but probably close), and in any case <br> +definitely not worth reviving BIP 9 with its known flaws and vulnerability.= +<br> +<br> +My review here is based solely on the BIP, with no outside context (aside f= +rom <br> +current consensus rules, of course). In particular, I have _not_ looked at = +<br> +the CTV code proposed for Bitcoin Core yet.<br> +<br> +>Covenants are restrictions on how a coin may be spent beyond key owners= +hip. <br> +<br> +nit: Poorly phrased. Even simple scripts can do that already.<br> +<br> +>A few examples are described below, which should be the subject of futu= +re <br> +non-consensus standardization efforts.<br> +<br> +I would ideally like to see fully implemented BIPs for at least one of thes= +e <br> +(preferably the claimed CoinJoin improvements) before we move toward <br> +activation.<br> +<br> +>Congestion Controlled Transactions<br> +<br> +I think this use case hasn't been fully thought through yet. It seems l= +ike it <br> +would be desirable for this purpose, to allow any of the recipients to clai= +m <br> +their portion of the payment without footing the fee for every other paymen= +t <br> +included in the batch. This is still a covenant-type solution, but one that= + <br> +BIP 119 cannot support as-is.<br> +<br> +(I realise this may be a known and accepted limitation, but I think it shou= +ld <br> +be addressed in the BIP)<br> +<br> +>Payment Channels<br> +<br> +Why batch mere channel creation? Seems like the spending transaction should= + <br> +really be the channel closing.<br> +<br> +>CHECKTEMPLATEVERIFY makes it much easier to set up trustless CoinJoins = +than <br> +previously because participants agree on a single output which pays all <br= +> +participants, which will be lower fee than before.<br> +<br> +I don't see how. They still have to agree in advance on the outputs, an= +d the <br> +total fees will logically be higher than not using CTV...?<br> +<br> +>Further Each participant doesn't need to know the totality of the o= +utputs <br> +committed to by that output, they only have to verify their own sub-tree wi= +ll <br> +pay them.<br> +<br> +I don't see any way to do this with the provided implementation.<br> +<br> +>Deployment could be done via BIP 9 VersionBits deployed through Speedy = +Trial.<br> +<br> +Hard NACK on this. BIP 9 at this point represents developers attempting to = +<br> +disregard and impose their will over community consensus, as well as an <br= +> +attempt to force a miner veto backdoor/vulnerability on deployment. It shou= +ld <br> +never be used again.<br> +<br> +Speedy Trial implemented with BIP 8 made sense* as a possible neutral <br> +compromise between LOT=3DTrue and LOT=3DFalse (which could be deployed prio= +r to <br> +or in parallel), but using BIP 9 would destroy this.<br> +<br> +As with Taproot, any future deployments should use BIP 8 again, until a bet= +ter <br> +solution is developed. Reverting back to a known flawed and vulnerable <br> +activation method should not be done, and it would be better not to deploy = +<br> +CTV at all at such an expense.<br> +<br> +The fact that certain developers attempted to deploy a BIP 9 alternative <b= +r> +activation for Taproot against community consensus, and that even managed t= +o <br> +get released as "Bitcoin Core", makes it all the more important t= +hat the <br> +community firmly rejects any further action to force this regression.<br> +<br> +* it is my opinion a BIP 8 ST would be an okay compromise under those <br> +circumstances; others do disagree that ST is acceptable at all<br> +<br> +> This ensures that for a given known input, the TXIDs can also be known= + ahead <br> +of time. Otherwise, CHECKTEMPLATEVERIFY would not be usable for Batched <br= +> +Channel Creation constructions as the redemption TXID could be malleated an= +d <br> +pre-signed transactions invalidated, unless the channels are built using an= + <br> +Eltoo-like protocol.<br> +<br> +Why is it a problem for them to use an Eltoo-like protocol?<br> +<br> +Why not just commit to the txid itself if that's the goal?<br> +<br> +>P2SH is incompatible with CHECKTEMPLATEVERIFY <br> +<br> +Maybe the CTV opcode should only be defined/enforced within witness scripts= +?<br> +<br> +>nLockTime should generally be fixed to 0 (in the case of a payment tree= +, only <br> +the *first* lock time is needed to prevent fee-sniping the root)<br> +<br> +Your "Congestion Controlled Transactions" example would only make= + sense with <br> +the spending transaction much later than the "root", and so could= + benefit <br> +from fee sniping malleability. (In fact, in that example, it would be bette= +r <br> +not to commit to locktime at all.)<br> +<br> +>In the CHECKTEMPLATEVERIFY approach, the covenants are severely restric= +ted to <br> +simple templates. The structure of CHECKTEMPLATEVERIFY template is such tha= +t <br> +the outputs must be known exactly at the time of construction. Based on a <= +br> +destructuring argument, it is only possible to create templates which expan= +d <br> +in a finite number of steps.<br> +<br> +It's not clear to me that this holds if OP_CAT or OP_SHA256STREAM get a= +dded.<br> +<br> +>For example, a exchange's hot wallet might use an address which can= + <br> +automatically be moved to a cold storage address after a relative timeout.<= +br> +<br> +Wouldn't it make more sense to just have a UTXO both cold+hot can spend= +, then <br> +throw away the hot key?<br> +<br> +>In contrast to previous forks, OP_CHECKTEMPLATEVERIFY will not make scr= +ipts <br> +valid for policy until the new rule is active.<br> +<br> +Policy isn't validity, and cannot be dictated by BIPs (or anyone/anythi= +ng, for <br> +that matter).<br> +<br> +Luke<br> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</blockquote></div> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"= + class=3D"gmail_signature"><br><br>Alex Schoof</div> + +--000000000000527c4005d5e496c1-- + |