Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 13DE7C002F for ; 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 ; 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 ; 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 ; Wed, 19 Jan 2022 00:37:16 +0000 (UTC) Received: by mail-lf1-x12d.google.com with SMTP id o15so2166865lfo.11 for ; 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> In-Reply-To: From: Alex Schoof Date: Tue, 18 Jan 2022 19:37:02 -0500 Message-ID: To: Jeremy , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > > > > 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
Hey Jeremy,=C2=A0

> On the topic of = drafting BIPs for specific use cases, I agree that would be valuable and ca= n consider it.
> 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.

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

Just a suggestio= n.=C2=A0

Cheers,

Alex

On Tue, Jan 18, 2022 at 6:54 PM Jeremy via bitcoin-d= ev <bitcoin-dev= @lists.linuxfoundation.org> wrote:
Thanks for the detailed revie= w.

I'll withhold=C2=A0comment around activation logic and l= eave that for others to discuss.
<= br>
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 covenant 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.

On the topic of drafting BIPs for specific use cases, I agree th= at 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 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.

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=A0h= ttps://bitcoin.stackexchange.com/questions/111666/support-for-taproot-multi= sig-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 po= sts in rubin.io/adve= nt21 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 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 https://learn.sapio-l= ang.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 o= f non-interactive channels be best written up as a BIP, a BLIP, or a descri= ptive blog/mailing list post?

=

On Tue, = Jan 18, 2022 at 1:19 PM Luke Dashjr via bitcoin-dev <bitcoin-dev@lists.l= inuxfoundation.org> wrote:
tl;dr: I don= 9;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 f= rom
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 owners= hip.

nit: Poorly phrased. Even simple scripts can do that already.

>A few examples are described below, which should be the subject of futu= re
non-consensus standardization efforts.

I would ideally like to see fully implemented BIPs for at least one of thes= e
(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 l= ike it
would be desirable for this purpose, to allow any of the recipients to clai= m
their portion of the payment without footing the fee for every other paymen= t
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 shou= ld
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, an= d the
total fees will logically be higher than not using CTV...?

>Further Each participant doesn't need to know the totality of the o= utputs
committed to by that output, they only have to verify their own sub-tree wi= ll
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 shou= ld
never be used again.

Speedy Trial implemented with BIP 8 made sense* as a possible neutral
compromise between LOT=3DTrue and LOT=3DFalse (which could be deployed prio= r to
or in parallel), but using BIP 9 would destroy this.

As with Taproot, any future deployments should use BIP 8 again, until a bet= ter
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 t= o
get released as "Bitcoin Core", makes it all the more important t= hat 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 an= d
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 bette= r
not to commit to locktime at all.)

>In the CHECKTEMPLATEVERIFY approach, the covenants are severely restric= ted to
simple templates. The structure of CHECKTEMPLATEVERIFY template is such tha= t
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
in a finite number of steps.

It's not clear to me that this holds if OP_CAT or OP_SHA256STREAM get a= dded.

>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.<= br>
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 scr= ipts
valid for policy until the new rule is active.

Policy isn't validity, and cannot be dictated by BIPs (or anyone/anythi= ng, for
that matter).

Luke
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev


--


Alex Schoof
--000000000000527c4005d5e496c1--