path: root/13/54ff5d0cb73c6e46a4d3928e0abab5fe60496d

Return-Path: <jlrubin@mit.edu>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 323FEC0881
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Nov 2019 19:59:59 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id 1B6FB87C5B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Nov 2019 19:59:59 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 56axgOMSZFHT
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Nov 2019 19:59:57 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
 by whitealder.osuosl.org (Postfix) with ESMTPS id 28F7B87C55
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Nov 2019 19:59:57 +0000 (UTC)
Received: from mail-io1-f45.google.com (mail-io1-f45.google.com
 [209.85.166.45]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xASJxtIT022062
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Thu, 28 Nov 2019 14:59:55 -0500
Received: by mail-io1-f45.google.com with SMTP id j13so30117844ioe.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Nov 2019 11:59:55 -0800 (PST)
X-Gm-Message-State: APjAAAVsp4pGJmbuUv0DmxC98CFomaXQ+Aco4eQiNdbkufjqYdXTuPU8
 kxldZAjI3Dke5pfWUlGEia6oMSCtj8MypR0KxF0=
X-Google-Smtp-Source: APXvYqzEhxbrWq/NCrTvxmY0qcNiuDLASnTKy8THbiLFETYD7/A1X0PXcMelCNV+dCnA7ioCaWfE0zH+Mtts6AGYcl4=
X-Received: by 2002:a6b:3b90:: with SMTP id
 i138mr27387360ioa.105.1574971194809; 
 Thu, 28 Nov 2019 11:59:54 -0800 (PST)
MIME-Version: 1.0
References: <CAD5xwhjXidpeLLUr4TO30t7U3z_zUxTpU9GBpLxu3MWX3ZFeTA@mail.gmail.com>
 <CAMZUoKkS77GwTW0B+cbh5BE5koB5oR4zbvEFmufAH7rN+CkR+w@mail.gmail.com>
In-Reply-To: <CAMZUoKkS77GwTW0B+cbh5BE5koB5oR4zbvEFmufAH7rN+CkR+w@mail.gmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Fri, 29 Nov 2019 04:59:42 +0900
X-Gmail-Original-Message-ID: <CAD5xwhi115pHK4J4=WDX=xbusxG_qP-oOWYNsD4z1Hh7JZ1yzQ@mail.gmail.com>
Message-ID: <CAD5xwhi115pHK4J4=WDX=xbusxG_qP-oOWYNsD4z1Hh7JZ1yzQ@mail.gmail.com>
To: "Russell O'Connor" <roconnor@blockstream.io>
Content-Type: multipart/alternative; boundary="0000000000009924f105986d8ef3"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Thu, 28 Nov 2019 19:59:59 -0000

--0000000000009924f105986d8ef3
Content-Type: text/plain; charset="UTF-8"

Thanks for the feedback Russell, now and early. It deeply informed the
version I'm proposing here.

I weighed carefully when selecting this design that I thought it would be
an acceptable tradeoff after our discussion, but I recognize this isn't
exactly what you had argued for.

First off, with respect to the 'global state' issue, I figured it was
reasonable with this choice of constexpr rule given that a reasonable tail
recursive parser might look something like:

parse (code : rest) stack alt_stack just_pushed =
    match code with
        OP_PUSH => parse rest (x:stack) alt_stack True
        OP_DUP => parse rest (x:stack) alt_stack False
        // ...

So we're only adding one parameter which is a bool, and we only need to
ever set it to an exact value based on the current code path, no
complicated rules. I'm sensitive to the complexity added when formally
modeling script, but I think because it is only ever a literal, you could
re-write it as co-recursive:

parse_non_constexpr (code : rest) stack alt_stack =
    match code with
        OP_PUSH => parse_constexpr rest (x:stack) alt_stack
        OP_DUP => parse_non_constexpr rest (x:stack) alt_stack
        // ...

parse_constexpr (code : rest) stack alt_stack  =
    match code with
        OP_CTV => ...
        _ => parese_non_constexpr (code : rest) stack alt_stack


If I recall, this should help a bit with the proof automatability as it's
easier in the case by case breakdown to see the unconditional code paths.


In terms of upgrade-ability, one of the other reasons I liked this design
is that if we do enable OP_CTV for non-constexpr arguments, the issue
basically goes away and the OP becomes "pure" without any state tracking.
(I think the switching on argument size is much less a concern because we
already use similar upgrade mechanisms elsewhere, and it doesn't add
parsing context).


It's also possible, as I think *should be done* for tooling to treat an
unbalanced OP_CTV as a parsing error. This will always produce
consensus-valid scripts! However by keeping the consensus rules more
relaxed we keep our upgrade-ability paths open for OP_CTV, which as I
understand from speaking with other users is quite desirable.


Best (and happy thanksgiving to those celebrating),

Jeremy

--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>


On Thu, Nov 28, 2019 at 6:33 AM Russell O'Connor <roconnor@blockstream.io>
wrote:

> 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>
>>
>

--0000000000009924f105986d8ef3
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 feedback R=
ussell, now and early. It deeply informed the version I&#39;m proposing her=
e.<br></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 weighed carefully when selecting this design that I thought =
it would be an acceptable tradeoff after our discussion, but I recognize th=
is isn&#39;t exactly what you had argued for.<br></div><div class=3D"gmail_=
default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co=
lor:#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:ar=
ial,helvetica,sans-serif;font-size:small;color:#000000">First off, with res=
pect to the &#39;global state&#39; issue, I figured it was reasonable with =
this choice of constexpr rule given that a reasonable tail recursive parser=
 might look something like:</div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div=
><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-ser=
if;font-size:small;color:#000000">parse (code : rest) stack alt_stack just_=
pushed =3D</div><div class=3D"gmail_default" style=3D"font-family:arial,hel=
vetica,sans-serif;font-size:small;color:#000000">=C2=A0=C2=A0=C2=A0 match c=
ode with</div><div class=3D"gmail_default" style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:#000000">=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 OP_PUSH =3D&gt; parse rest (x:stack) alt_stack True</div><d=
iv class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;=
font-size:small;color:#000000">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 O=
P_DUP =3D&gt; parse rest (x:stack) alt_stack False</div><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:#000000">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // ...</div><div c=
lass=3D"gmail_default" style=3D"font-family:arial,helvetica,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;color:#000000">So we=
&#39;re only adding one parameter which is a bool, and we only need to ever=
 set it to an exact value based on the current code path, no complicated ru=
les. I&#39;m sensitive to the complexity added when formally modeling scrip=
t, but I think because it is only ever a literal, you could re-write it as =
co-recursive:</div><div class=3D"gmail_default" style=3D"font-family:arial,=
helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D=
"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:s=
mall;color:#000000"><div class=3D"gmail_default" style=3D"font-family:arial=
,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">parse_non_constexpr=
 (code : rest) stack alt_stack =3D</div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
">=C2=A0=C2=A0=C2=A0 match code with</div><div class=3D"gmail_default" styl=
e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0=
)">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OP_PUSH =3D&gt; parse_constex=
pr rest (x:stack) alt_stack<br></div><div class=3D"gmail_default" style=3D"=
font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OP_DUP =3D&gt; parse_non_constex=
pr rest (x:stack) alt_stack<br></div><div class=3D"gmail_default" style=3D"=
font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // ...</div><div class=3D"gmail_=
default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co=
lor:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family=
:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><div class=3D=
"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:s=
mall;color:rgb(0,0,0)">parse_constexpr (code : rest) stack alt_stack=C2=A0 =
=3D</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,=
sans-serif;font-size:small;color:rgb(0,0,0)">=C2=A0=C2=A0=C2=A0 match code =
with</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica=
,sans-serif;font-size:small;color:rgb(0,0,0)">=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 OP_CTV =3D&gt; ...</div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 _ =3D&gt; parese_non_constexpr=
 (code : rest) stack alt_stack</div><div class=3D"gmail_default" style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br=
></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sa=
ns-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_de=
fault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;colo=
r:rgb(0,0,0)">If I recall, this should help a bit with the proof automatabi=
lity as it&#39;s easier in the case by case breakdown to see the unconditio=
nal code paths.</div><div class=3D"gmail_default" style=3D"font-family:aria=
l,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D=
"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">I=
n terms of upgrade-ability, one of the other reasons I liked this design is=
 that if we do enable OP_CTV for non-constexpr arguments, the issue basical=
ly goes away and the OP becomes &quot;pure&quot; without any state tracking=
. (I think the switching on argument size is much less a concern because we=
 already use similar upgrade mechanisms elsewhere, and it doesn&#39;t add p=
arsing context).</div><div class=3D"gmail_default" style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div cl=
ass=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" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
">It&#39;s also possible, as I think *should be done* for tooling to treat =
an unbalanced OP_CTV as a parsing error. This will always produce consensus=
-valid scripts! However by keeping the consensus rules more relaxed we keep=
 our upgrade-ability paths open for OP_CTV, which as I understand from spea=
king with other users is quite desirable. <br></div><div class=3D"gmail_def=
ault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color=
:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family:ar=
ial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div c=
lass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font=
-size:small;color:rgb(0,0,0)">Best (and happy thanksgiving to those celebra=
ting),</div><div class=3D"gmail_default" style=3D"font-family:arial,helveti=
ca,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gma=
il_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small=
;color:rgb(0,0,0)">Jeremy<br></div></div></div><div class=3D"gmail_default"=
 style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000=
000"><br></div><div><div dir=3D"ltr" data-smartmail=3D"gmail_signature"><di=
v 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 Thu, Nov 28, 2019 at 6:33 AM Russe=
ll O&#39;Connor &lt;<a href=3D"mailto:roconnor@blockstream.io" target=3D"_b=
lank">roconnor@blockstream.io</a>&gt; wrote:<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Thanks for this work Jer=
emy.</div><div><br></div><div dir=3D"ltr">I know we&#39;ve discussed this b=
efore, but I&#39;ll restate my concerns with adding a new &quot;global&quot=
; state variable to the Script interpreter for tracking whether the previou=
s opcode was a push-data operation or not.=C2=A0 While it isn&#39;t so hard=
 to implement this in Bitcoin Core&#39;s Script interpreter, adding a new g=
lobal state variable adds that much more complexity to anyone trying to for=
mally model Script semantics.=C2=A0 Perhaps one can argue that there is alr=
eady (non-stack) state in Script, e.g. to deal with CODESEPARATOR, so why n=
ot add more?=C2=A0 But I&#39;d argue that we should avoid making bad proble=
ms worse.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">If we instead ma=
ke the CHECKTEMPLATEVERIFY operation fail if it isn&#39;t preceded by (or a=
lternatively followed by) an appropriate sized (canonical?) PUSHDATA consta=
nt, 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 implementations to consider improper use of CHECKTEMPLA=
TEVERIFY 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 implement=
ed in Bitcoin Core).<br></div><div dir=3D"ltr"><br></div><div>I admit we wo=
uld lose your soft-fork upgrade path to reading values off the stack; howev=
er, in my opinion, this is a reasonable tradeoff.=C2=A0 When we are ready t=
o add programmable covenants to Script, we&#39;ll do so by adding CAT and o=
perations to push transaction data right onto the stack, rather than postin=
g a preimage to this template hash.<br></div><div dir=3D"ltr"><br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex"><div style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Pleased to announce re=
finements to the BIP draft for OP_CHECKTEMPLATEVERIFY (replaces previous OP=
_SECURETHEBAG BIP). Primarily:</div><div style=3D"font-family:arial,helveti=
ca,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">1) Ch=
anged the name to something more fitting and acceptable to the community<br=
></div><div style=3D"font-family: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 primitive constexpr/literal tracker rather than scr=
ipt lookahead</div><div style=3D"font-family:arial,helvetica,sans-serif;fon=
t-size:small;color:rgb(0,0,0)">3) Permits future soft-fork updates to loose=
n or remove &quot;constexpr&quot; restrictions</div><div style=3D"font-fami=
ly:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">4) More det=
ailed comparison to alternatives in the BIP, and why OP_CHECKTEMPLATEVERIFY=
 should be favored even if a future technique may make it semi-redundant.<b=
r></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:smal=
l;color:rgb(0,0,0)"><br></div><div style=3D"font-family:arial,helvetica,san=
s-serif;font-size:small;color:rgb(0,0,0)">Please see:</div><div style=3D"fo=
nt-family:arial,helvetica,sans-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://github.com/JeremyRubin/bips/blob/ctv/bip-ctv.med=
iawiki</a></div><div><div style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:rgb(0,0,0)">Reference Implementation:<a href=3D"https:=
//github.com/JeremyRubin/bitcoin/tree/checktemplateverify" target=3D"_blank=
"> https://github.com/JeremyRubin/bitcoin/tree/checktemplateverify</a></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)">I believe this addresses all outstanding=
 feedback on the design of this opcode, unless there are any new concerns w=
ith these changes.<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)">I&#39;m also =
planning to host a review workshop in Q1 2020, most likely in San Francisco=
. Please fill out the form here <a href=3D"https://forms.gle/pkevHNj2pXH9MG=
ee9" target=3D"_blank">https://forms.gle/pkevHNj2pXH9MGee9</a> if you&#39;r=
e interested in participating (even if you can&#39;t physically attend).<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)">And as a &quot;but wait, there&#39=
;s more&quot;:<br></div><div style=3D"font-family:arial,helvetica,sans-seri=
f;font-size:small;color:rgb(0,0,0)"><br></div><div style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">1) RPC functions =
are under preliminary development, to aid in testing and evaluation of OP_C=
HECKTEMPLATEVERIFY. The new command `sendmanycompacted` shows one way to us=
e OP_CHECKTEMPLATEVERIFY. See: <a href=3D"https://github.com/JeremyRubin/bi=
tcoin/tree/checktemplateverify-rpcs" target=3D"_blank">https://github.com/J=
eremyRubin/bitcoin/tree/checktemplateverify-rpcs</a>. `sendmanycompacted` i=
s still under early design. Standard practices for using OP_CHECKTEMPLATEVE=
RIFY &amp; wallet behaviors may be codified into a separate BIP. This work =
generalizes even if an alternative strategy is used to achieve the scalabil=
ity techniques of OP_CHECKTEMPLATEVERIFY.<br></div><div style=3D"font-famil=
y:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">2) Also unde=
r development are improvements to the mempool which will, in conjunction wi=
th improvements like package relay, help make it safe to lift some of the m=
empool&#39;s restrictions on longchains specifically for OP_CHECKTEMPLATEVE=
RIFY output trees. See: <a href=3D"https://github.com/bitcoin/bitcoin/pull/=
17268" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/17268 </a>=
This work offers an improvement 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,helv=
etica,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)">Ne=
ither of these are blockers for proceeding with the BIP, as they are ergono=
mics and usability improvements needed once/if the BIP is activated.<br></d=
iv><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;col=
or:rgb(0,0,0)"><br></div></div><div><div style=3D"font-family:arial,helveti=
ca,sans-serif;font-size:small;color:rgb(0,0,0)">See prior mailing list disc=
ussions here:</div><div style=3D"font-family:arial,helvetica,sans-serif;fon=
t-size:small;color:rgb(0,0,0)"><br></div><div style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:rgb(0,0,0)">* <a href=3D"https://l=
ists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016934.html" target=
=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-Ma=
y/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.linuxfoundati=
on.org/pipermail/bitcoin-dev/2019-June/016997.html" target=3D"_blank">https=
://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/016997.html</a=
></div></div><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,hel=
vetica,sans-serif;font-size:small;color:rgb(0,0,0)">Thanks to the many deve=
lopers who have provided feedback on iterations of this design.<br></div><d=
iv style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rg=
b(0,0,0)"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;fo=
nt-size:small;color:rgb(0,0,0)">Best,</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)=
">Jeremy</div><br></div><div><div dir=3D"ltr"><div dir=3D"ltr">--<br><a hre=
f=3D"https://twitter.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a></d=
iv></div></div></blockquote></div></div>
</blockquote></div>

--0000000000009924f105986d8ef3--