path: root/43/f958fd1ab4239d55e082ab119986685e91cbcb

Return-Path: <roconnor@blockstream.io>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id AED84C0881
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 27 Nov 2019 22:38:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by silver.osuosl.org (Postfix) with ESMTP id AA750203F3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 27 Nov 2019 22:38:24 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id vnG8vsbud5wH
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 27 Nov 2019 22:38:23 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-qk1-f171.google.com (mail-qk1-f171.google.com
 [209.85.222.171])
 by silver.osuosl.org (Postfix) with ESMTPS id 064B1203E1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 27 Nov 2019 22:38:22 +0000 (UTC)
Received: by mail-qk1-f171.google.com with SMTP id f5so2669882qkm.13
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 27 Nov 2019 14:38:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=blockstream.io; s=google;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=CpKs8ELomr2LegFpo57YvOmw5YdU8ljAosS+KzWTXQI=;
 b=xw4oPQLG3DhChsNUpL+RU8IkuBU1JyPP9U/L7B89yDUt7yqFOqb23P2SNlLH5csSLY
 ARyl1rHiqvQtqC8GVXimj8ycT/8pA4sfLQ01R4kt1iPUFfLho075G1Mh+FtekQQljPB1
 8QauufKW4iUd3ad47EmZWTjZoeJ2+OnoNNVNc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=CpKs8ELomr2LegFpo57YvOmw5YdU8ljAosS+KzWTXQI=;
 b=rvjyZhYO57hGT/MC9xPDg/po0nwuaT3Tos5n2+3ALye+lHih+c3UUdUIvC93IEoLrG
 XOBZu93lV3/XCUSy8czbiTK2CPRPZLTrC5dPmr7SSNgzA6Ryi/mldLloD8RXyJSHHB8m
 9QTCYXm2zAX2+OIQgB04cHvXj6sCObuN5MxWymtbiFqaJlB3WKZ2OPUmjYCRL1VurEES
 u1ptOd0WnipbhQpbYOwA45tbq9FX98b0LKOQjNsQ3Ac8qfYhCl3BmleYHC1Ni7PHqIyH
 yc8bQU709Om6j7EebGi03CrC21i5O9aTeejsM1Le63/4qqjXcde38VWjYOd96i1kYlHu
 37qg==
X-Gm-Message-State: APjAAAUNSTgCPSAI7xUSpZuci2thVRROhy+rGYm984aw+EB4eEwNUWXy
 yEm7TBJL5lViEsjxq14OwqNqjsm4mGWOFliFnNDy7xTe
X-Google-Smtp-Source: APXvYqwiqsh36hT/xCZTQo/ivC7+4aC3im1KKRNVyoNlhczNFFRRQ6Ao7yoze57Ooo2SalUZIKdUyq57w2F98BSECLs=
X-Received: by 2002:a05:6638:762:: with SMTP id
 y2mr6388618jad.78.1574890382511; 
 Wed, 27 Nov 2019 13:33:02 -0800 (PST)
MIME-Version: 1.0
References: <CAD5xwhjXidpeLLUr4TO30t7U3z_zUxTpU9GBpLxu3MWX3ZFeTA@mail.gmail.com>
In-Reply-To: <CAD5xwhjXidpeLLUr4TO30t7U3z_zUxTpU9GBpLxu3MWX3ZFeTA@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Wed, 27 Nov 2019 16:32:51 -0500
Message-ID: <CAMZUoKkS77GwTW0B+cbh5BE5koB5oR4zbvEFmufAH7rN+CkR+w@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000cf6fe705985abd1c"
Subject: Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY
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, 27 Nov 2019 22:38:24 -0000

--000000000000cf6fe705985abd1c
Content-Type: text/plain; charset="UTF-8"

Thanks for this work Jeremy.

I know we've discussed this before, but I'll restate my concerns with
adding a new "global" state variable to the Script interpreter for tracking
whether the previous opcode was a push-data operation or not.  While it
isn't so hard to implement this in Bitcoin Core's Script interpreter,
adding a new global state variable adds that much more complexity to anyone
trying to formally model Script semantics.  Perhaps one can argue that
there is already (non-stack) state in Script, e.g. to deal with
CODESEPARATOR, so why not add more?  But I'd argue that we should avoid
making bad problems worse.

If we instead make the CHECKTEMPLATEVERIFY operation fail if it isn't
preceded by (or alternatively followed by) an appropriate sized
(canonical?) PUSHDATA constant, even in an unexecuted IF branch, then we
can model the Script semantics by considering the
PUSHDATA-CHECKTEMPLATEVERIFY pair as a single operation.  This allows
implementations to consider improper use of CHECKTEMPLATEVERIFY as a
parsing error (just as today unbalanced IF-ENDIF pairs can be modeled as a
parsing error, even though that isn't how it is implemented in Bitcoin
Core).

I admit we would lose your soft-fork upgrade path to reading values off the
stack; however, in my opinion, this is a reasonable tradeoff.  When we are
ready to add programmable covenants to Script, we'll do so by adding CAT
and operations to push transaction data right onto the stack, rather than
posting a preimage to this template hash.

Pleased to announce refinements to the BIP draft for OP_CHECKTEMPLATEVERIFY
> (replaces previous OP_SECURETHEBAG BIP). Primarily:
>
> 1) Changed the name to something more fitting and acceptable to the
> community
> 2) Changed the opcode specification to use the argument off of the stack
> with a primitive constexpr/literal tracker rather than script lookahead
> 3) Permits future soft-fork updates to loosen or remove "constexpr"
> restrictions
> 4) More detailed comparison to alternatives in the BIP, and why
> OP_CHECKTEMPLATEVERIFY should be favored even if a future technique may
> make it semi-redundant.
>
> Please see:
> BIP: https://github.com/JeremyRubin/bips/blob/ctv/bip-ctv.mediawiki
> Reference Implementation:
> https://github.com/JeremyRubin/bitcoin/tree/checktemplateverify
>
> I believe this addresses all outstanding feedback on the design of this
> opcode, unless there are any new concerns with these changes.
>
> I'm also planning to host a review workshop in Q1 2020, most likely in San
> Francisco. Please fill out the form here
> https://forms.gle/pkevHNj2pXH9MGee9 if you're interested in participating
> (even if you can't physically attend).
>
> And as a "but wait, there's more":
>
> 1) RPC functions are under preliminary development, to aid in testing and
> evaluation of OP_CHECKTEMPLATEVERIFY. The new command `sendmanycompacted`
> shows one way to use OP_CHECKTEMPLATEVERIFY. See:
> https://github.com/JeremyRubin/bitcoin/tree/checktemplateverify-rpcs.
> `sendmanycompacted` is still under early design. Standard practices for
> using OP_CHECKTEMPLATEVERIFY & wallet behaviors may be codified into a
> separate BIP. This work generalizes even if an alternative strategy is used
> to achieve the scalability techniques of OP_CHECKTEMPLATEVERIFY.
> 2) Also under development are improvements to the mempool which will, in
> conjunction with improvements like package relay, help make it safe to lift
> some of the mempool's restrictions on longchains specifically for
> OP_CHECKTEMPLATEVERIFY output trees. See: https://github.com/bitcoin/bitcoin/pull/17268
> This work offers an improvement irrespective of OP_CHECKTEMPLATEVERIFY's
> fate.
>
>
> Neither of these are blockers for proceeding with the BIP, as they are
> ergonomics and usability improvements needed once/if the BIP is activated.
>
> See prior mailing list discussions here:
>
> *
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016934.html
> *
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/016997.html
>
> Thanks to the many developers who have provided feedback on iterations of
> this design.
>
> Best,
>
> Jeremy
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
>

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

<div dir=3D"ltr"><div>Thanks for this work Jeremy.</div><div><br></div><div=
 dir=3D"ltr">I know we&#39;ve discussed this before, but I&#39;ll restate m=
y concerns with adding a new &quot;global&quot; state variable to the Scrip=
t interpreter for tracking whether the previous opcode was a push-data oper=
ation or not.=C2=A0 While it isn&#39;t so hard to implement this in Bitcoin=
 Core&#39;s Script interpreter, adding a new global state variable adds tha=
t much more complexity to anyone trying to formally model Script semantics.=
=C2=A0 Perhaps one can argue that there is already (non-stack) state in Scr=
ipt, e.g. to deal with CODESEPARATOR, so why not add more?=C2=A0 But I&#39;=
d argue that we should avoid making bad problems worse.</div><div dir=3D"lt=
r"><br></div><div dir=3D"ltr">If we instead make the CHECKTEMPLATEVERIFY op=
eration fail if it isn&#39;t preceded by (or alternatively followed by) an =
appropriate sized (canonical?) PUSHDATA constant, even in an unexecuted IF =
branch, then we can model the Script semantics by considering the PUSHDATA-=
CHECKTEMPLATEVERIFY pair as a single operation.=C2=A0 This allows implement=
ations to consider improper use of CHECKTEMPLATEVERIFY as a parsing error (=
just as today unbalanced IF-ENDIF pairs can be modeled as a parsing error, =
even though that isn&#39;t how it is implemented in Bitcoin Core).<br></div=
><div dir=3D"ltr"><br></div><div>I admit we would lose your soft-fork upgra=
de path to reading values off the stack; however, in my opinion, this is a =
reasonable tradeoff.=C2=A0 When we are ready to add programmable covenants =
to Script, we&#39;ll do so by adding CAT and operations to push transaction=
 data right onto the stack, rather than posting a preimage to this template=
 hash.<br></div><div dir=3D"ltr"><br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div style=3D"font-family:arial,helvetica,sans-serif;font-size:=
small;color:rgb(0,0,0)">Pleased to announce refinements to the BIP draft fo=
r OP_CHECKTEMPLATEVERIFY (replaces previous OP_SECURETHEBAG BIP). Primarily=
:</div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small=
;color:rgb(0,0,0)"><br></div><div style=3D"font-family:arial,helvetica,sans=
-serif;font-size:small;color:rgb(0,0,0)">1) Changed the name to something m=
ore fitting and acceptable to the community<br></div><div style=3D"font-fam=
ily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">2) Changed=
 the opcode specification to use the argument off of the stack with a primi=
tive constexpr/literal tracker rather than script lookahead</div><div style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
">3) Permits future soft-fork updates to loosen or remove &quot;constexpr&q=
uot; restrictions</div><div style=3D"font-family:arial,helvetica,sans-serif=
;font-size:small;color:rgb(0,0,0)">4) More detailed comparison to alternati=
ves in the BIP, and why OP_CHECKTEMPLATEVERIFY should be favored even if a =
future technique may make it semi-redundant.<br></div><div style=3D"font-fa=
mily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div=
><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color=
:rgb(0,0,0)">Please see:</div><div style=3D"font-family:arial,helvetica,san=
s-serif;font-size:small;color:rgb(0,0,0)">BIP:<a href=3D"https://github.com=
/JeremyRubin/bips/blob/ctv/bip-ctv.mediawiki" target=3D"_blank"> https://gi=
thub.com/JeremyRubin/bips/blob/ctv/bip-ctv.mediawiki</a></div><div><div sty=
le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,=
0)">Reference Implementation:<a href=3D"https://github.com/JeremyRubin/bitc=
oin/tree/checktemplateverify" target=3D"_blank"> https://github.com/JeremyR=
ubin/bitcoin/tree/checktemplateverify</a></div><div style=3D"font-family:ar=
ial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div s=
tyle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,=
0,0)">I believe this addresses all outstanding feedback on the design of th=
is opcode, unless there are any new concerns with these changes.<br></div><=
div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:r=
gb(0,0,0)"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:rgb(0,0,0)">I&#39;m also planning to host a review wor=
kshop in Q1 2020, most likely in San Francisco. Please fill out the form he=
re <a href=3D"https://forms.gle/pkevHNj2pXH9MGee9" target=3D"_blank">https:=
//forms.gle/pkevHNj2pXH9MGee9</a> if you&#39;re interested in participating=
 (even if you can&#39;t physically attend).<br></div><div style=3D"font-fam=
ily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div>=
<div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:=
rgb(0,0,0)">And as a &quot;but wait, there&#39;s more&quot;:<br></div><div =
style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0=
,0,0)"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:rgb(0,0,0)">1) RPC functions are under preliminary develop=
ment, to aid in testing and evaluation of OP_CHECKTEMPLATEVERIFY. The new c=
ommand `sendmanycompacted` shows one way to use OP_CHECKTEMPLATEVERIFY. See=
: <a href=3D"https://github.com/JeremyRubin/bitcoin/tree/checktemplateverif=
y-rpcs" target=3D"_blank">https://github.com/JeremyRubin/bitcoin/tree/check=
templateverify-rpcs</a>. `sendmanycompacted` is still under early design. S=
tandard practices for using OP_CHECKTEMPLATEVERIFY &amp; wallet behaviors m=
ay be codified into a separate BIP. This work generalizes even if an altern=
ative strategy is used to achieve the scalability techniques of OP_CHECKTEM=
PLATEVERIFY.<br></div><div style=3D"font-family:arial,helvetica,sans-serif;=
font-size:small;color:rgb(0,0,0)">2) Also under development are improvement=
s to the mempool which will, in conjunction with improvements like package =
relay, help make it safe to lift some of the mempool&#39;s restrictions on =
longchains specifically for OP_CHECKTEMPLATEVERIFY output trees. See: <a hr=
ef=3D"https://github.com/bitcoin/bitcoin/pull/17268" target=3D"_blank">http=
s://github.com/bitcoin/bitcoin/pull/17268 </a>This work offers an improveme=
nt irrespective of OP_CHECKTEMPLATEVERIFY&#39;s fate.<br></div><div style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:=
small;color:rgb(0,0,0)"><br></div><div style=3D"font-family:arial,helvetica=
,sans-serif;font-size:small;color:rgb(0,0,0)">Neither of these are blockers=
 for proceeding with the BIP, as they are ergonomics and usability improvem=
ents needed once/if the BIP is activated.<br></div><div style=3D"font-famil=
y:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div></=
div><div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll;color:rgb(0,0,0)">See prior mailing list discussions here:</div><div sty=
le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,=
0)"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:rgb(0,0,0)">* <a href=3D"https://lists.linuxfoundation.org/pi=
permail/bitcoin-dev/2019-May/016934.html" target=3D"_blank">https://lists.l=
inuxfoundation.org/pipermail/bitcoin-dev/2019-May/016934.html</a></div><div=
 style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(=
0,0,0)">* <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-de=
v/2019-June/016997.html" target=3D"_blank">https://lists.linuxfoundation.or=
g/pipermail/bitcoin-dev/2019-June/016997.html</a></div></div><div><div styl=
e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0=
)"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size=
:small;color:rgb(0,0,0)">Thanks to the many developers who have provided fe=
edback on iterations of this design.<br></div><div style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div st=
yle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0=
,0)">Best,</div><div style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:rgb(0,0,0)"><br></div><div style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:rgb(0,0,0)">Jeremy</div><br></div><di=
v><div dir=3D"ltr"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/Je=
remyRubin" target=3D"_blank">@JeremyRubin</a></div></div></div></blockquote=
></div></div>

--000000000000cf6fe705985abd1c--