path: root/86/569c1d30f089518cc0a7f021d378a17507106b

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>&gt; 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">&gt; However, I&#39;m a bi=
t skeptical of that approach overall as I don&#39;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 &quot;data sheet&quot; and a set=
 of &quot;application notes&quot;. 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&#39;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 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev=
@lists.linuxfoundation.org</a>&gt; 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&#39;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&#39;ll make a PR th=
at (I hope) clears up the small nits later today or tomorrow. Some of it&#3=
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.&quot; so I do think things like CLTV/CSV are covenants since it=
&#39;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&#39;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&#39;m a bit skeptical of=
 that approach overall as I don&#39;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 &#39;release&#39;.</=
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&#39;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&#39;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&#39;s an interesting discussion too because as we&#39=
;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 &lt;<a href=3D"mailto:b=
itcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.l=
inuxfoundation.org</a>&gt; 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&#3=
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>
&gt;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>
&gt;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>
&gt;Congestion Controlled Transactions<br>
<br>
I think this use case hasn&#39;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>
&gt;Payment Channels<br>
<br>
Why batch mere channel creation? Seems like the spending transaction should=
 <br>
really be the channel closing.<br>
<br>
&gt;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&#39;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>
&gt;Further Each participant doesn&#39;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&#39;t see any way to do this with the provided implementation.<br>
<br>
&gt;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 &quot;Bitcoin Core&quot;, 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>
&gt; 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&#39;s the goal?<br>
<br>
&gt;P2SH is incompatible with CHECKTEMPLATEVERIFY <br>
<br>
Maybe the CTV opcode should only be defined/enforced within witness scripts=
?<br>
<br>
&gt;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 &quot;Congestion Controlled Transactions&quot; example would only make=
 sense with <br>
the spending transaction much later than the &quot;root&quot;, 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>
&gt;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&#39;s not clear to me that this holds if OP_CAT or OP_SHA256STREAM get a=
dded.<br>
<br>
&gt;For example, a exchange&#39;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&#39;t it make more sense to just have a UTXO both cold+hot can spend=
, then <br>
throw away the hot key?<br>
<br>
&gt;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&#39;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--