path: root/0d/24d0ec2ec0197e79adb593825b6f4d18c7b3c4

Return-Path: <jlrubin@mit.edu>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 72851C002F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Jan 2022 23:54:37 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 5A6E7410D2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Jan 2022 23:54:37 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id iLgAO4DveGeN
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Jan 2022 23:54:35 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 7F2C6409D4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Jan 2022 23:54:35 +0000 (UTC)
Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com
 [209.85.167.54]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 20INsWMI015902
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Tue, 18 Jan 2022 18:54:33 -0500
Received: by mail-lf1-f54.google.com with SMTP id d3so1814869lfv.13
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Jan 2022 15:54:33 -0800 (PST)
X-Gm-Message-State: AOAM532aIeYR3tJzRJ8Q6M0/Xd++y6mFSx0yzI14ib+8Kb3aQ9E9ufn8
 kwY7nCOd9yNzR9d3P0daK/YnIaNrk45HxJGFbdE=
X-Google-Smtp-Source: ABdhPJyDRdrunRjbYsW2NxpQOppZJ+TVgnncJl8UZCa/en9rBSdmmEtUno+mLYuviIP9SgxrYaZyOdc6/N1AY2XZjHE=
X-Received: by 2002:a05:6512:1113:: with SMTP id
 l19mr996750lfg.226.1642550072060; 
 Tue, 18 Jan 2022 15:54:32 -0800 (PST)
MIME-Version: 1.0
References: <202201182119.02687.luke@dashjr.org>
In-Reply-To: <202201182119.02687.luke@dashjr.org>
From: Jeremy <jlrubin@mit.edu>
Date: Tue, 18 Jan 2022 15:54:21 -0800
X-Gmail-Original-Message-ID: <CAD5xwhh3d1=KXEJOPVuYm3UqNKovrojqJS-c6r6ficsKf6S_7g@mail.gmail.com>
Message-ID: <CAD5xwhh3d1=KXEJOPVuYm3UqNKovrojqJS-c6r6ficsKf6S_7g@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000922f6705d5e3fd16"
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: Tue, 18 Jan 2022 23:54:37 -0000

--000000000000922f6705d5e3fd16
Content-Type: text/plain; charset="UTF-8"

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
>

--000000000000922f6705d5e3fd16
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">Thanks for the detailed r=
eview.</div><div class=3D"gmail_default" style=3D"font-family:arial,helveti=
ca,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_=
default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co=
lor:#000000">I&#39;ll withhold=C2=A0comment around activation logic and lea=
ve that for others to discuss.</div><div class=3D"gmail_default" style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></=
div><div class=3D"gmail_default"><font color=3D"#000000" face=3D"arial, hel=
vetica, sans-serif">w.r.t. the language cleanups I&#39;ll make a PR that (I=
 hope) clears up the small nits later today or tomorrow. Some of it&#39;s k=
ind of annoying because the legal definition of covena</font>nt is &quot;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.&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 o=
f scope for the BIP to fully define these terms because it doesn&#39;t real=
ly matter what a covenant could be as much as it matters what CTV is specif=
ically.</div><div class=3D"gmail_default"><br></div><div class=3D"gmail_def=
ault">On the topic of drafting BIPs for specific use cases, I agree that wo=
uld 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 applications *m=
ust 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 wa=
nt to use it.</div><div class=3D"gmail_default"><br></div><div class=3D"gma=
il_default">E.g., we do not yet have a BIP for MuSig or even Multisig in Ta=
proot, although there are some papers and example implementations but nothi=
ng formal yet =C2=A0<a href=3D"https://bitcoin.stackexchange.com/questions/=
111666/support-for-taproot-multisig-descriptors">https://bitcoin.stackexcha=
nge.com/questions/111666/support-for-taproot-multisig-descriptors</a>). Per=
haps this is an opportunity for CTV to lead on the amount of formal applica=
tion designs available before &#39;release&#39;.</div><div class=3D"gmail_d=
efault"><br></div><div class=3D"gmail_default">As a starting point, maybe y=
ou could review some of the application focused posts in <a href=3D"http://=
rubin.io/advent21">rubin.io/advent21</a> and let me know where they seem de=
ficient?</div><div class=3D"gmail_default"><br></div><div class=3D"gmail_de=
fault">Also a BIP describing how to build something like Sapio (and less so=
 Sapio itself, since it&#39;s still early days for that) might help for fol=
ks to be able to think through how to compile to CTV contracts? But again, =
I&#39;m skeptical of the value of a BIP v.s. the documentation and examples=
 available in the code and <a href=3D"https://learn.sapio-lang.org">https:/=
/learn.sapio-lang.org</a>.</div><div class=3D"gmail_default"><br></div><div=
 class=3D"gmail_default">I think it&#39;s an interesting discussion too bec=
ause as we&#39;ve just seen the LN ecosystem start the BLIP standards, woul=
d an example of non-interactive channels be best written up as a BIP, a BLI=
P, or a descriptive blog/mailing list post?</div><div class=3D"gmail_defaul=
t" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#0=
00000"><br></div><div><div dir=3D"ltr" data-smartmail=3D"gmail_signature"><=
div dir=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyRubin" target=3D=
"_blank">@JeremyRubin</a><a href=3D"https://twitter.com/JeremyRubin" target=
=3D"_blank"></a></div></div></div><br></div><br><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:bitcoin-dev@lists.linuxfoundat=
ion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wr=
ote:<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&#39;t think CTV is ready yet (b=
ut 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>

--000000000000922f6705d5e3fd16--