path: root/04/94ca39a98f4a922172e3fe4df7f4c545165d6a

Return-Path: <jlrubin@mit.edu>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id B8681265
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 25 May 2019 01:08:16 +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 smtp1.linuxfoundation.org (Postfix) with ESMTPS id 941176C5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 25 May 2019 01:08:15 +0000 (UTC)
Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com
	[209.85.208.52]) (authenticated bits=0)
	(User authenticated as jlrubin@ATHENA.MIT.EDU)
	by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x4P18CbM015295
	(version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 24 May 2019 21:08:14 -0400
Received: by mail-ed1-f52.google.com with SMTP id w11so16768131edl.5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 24 May 2019 18:08:13 -0700 (PDT)
X-Gm-Message-State: APjAAAV2bBysbpxDR9gWiwgnKD19dRf1rMyuilpWNWwd2Yln4Dfi2UJa
	nnl6lS9ZnOpgRRwNkhlipS9cKlp5UraJl5IbGpM=
X-Google-Smtp-Source: APXvYqwOQai491rSkoktsvjWOrs3GholmLcuade0HwDkDl+qxdcUI5o3r9CUqnmdWkWP+0NHintPrPBWKe/N9PaXmrM=
X-Received: by 2002:a17:906:7cd2:: with SMTP id
	h18mr48859262ejp.267.1558746492610; 
	Fri, 24 May 2019 18:08:12 -0700 (PDT)
MIME-Version: 1.0
References: <CAMZUoK=0YhqxguphmaKsMGZCy_NYVE_i53qGBfPVES=GAYTy1g@mail.gmail.com>
	<CAD5xwhgVeTPP23SLrMrvXe6ApZyuuQq4us5z7wrPeJkx1+FSYA@mail.gmail.com>
	<CAMZUoKkA4UFivR4xpFcSRE6ThtYawXh9M8my1HnKv34i4o6FJw@mail.gmail.com>
In-Reply-To: <CAMZUoKkA4UFivR4xpFcSRE6ThtYawXh9M8my1HnKv34i4o6FJw@mail.gmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Fri, 24 May 2019 18:08:00 -0700
X-Gmail-Original-Message-ID: <CAD5xwhi9YoJ30xOo++mxqLeeGV7gy5kkucUSGzPJ9BkVVKxbfg@mail.gmail.com>
Message-ID: <CAD5xwhi9YoJ30xOo++mxqLeeGV7gy5kkucUSGzPJ9BkVVKxbfg@mail.gmail.com>
To: "Russell O'Connor" <roconnor@blockstream.io>
Content-Type: multipart/alternative; boundary="000000000000fcb08b0589abf2bd"
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Sat, 25 May 2019 12:07:05 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Sat, 25 May 2019 01:08:16 -0000

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

What do you think about having it be OP_CHECK_TXID_TEMPLATE_DATA where the
hash checked is the TXID of the transaction with the inputs set to 0000...
(maybe appended to the fee paid)?

This allows for a variable number of inputs to be allowed (e.g., one, two,
etc). This also fixes potential bugs around TXID malleability for lightning
like setups (Greg and I discussed in wizards about version malleability).

Allowing multiple inputs is great for structuring more complex contracts
with multiple nodes paying into the same covenantted transaction.

Also I personally prefer a RISC+CISC approach -- we should enable the
common paths easily as they are known (didn't you come up with jets?) and
improve security for API users, but also piecemeal enable features in
script to allow for experimentation or custom contracts.
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>


On Fri, May 24, 2019 at 4:15 PM Russell O'Connor <roconnor@blockstream.io>
wrote:

> In order of escalating scope of amendments to OP_COSHV, I suggest
>
> 1) Peeking at surrounding data surrounding data should definitely be
> replaced by a pushdata-like op-code that uses the subsequent 32-bytes
> directly.  The OP_SUCCESSx upgrade path specifically allows for this, and
> avoids complicating the semantics Bitcoin Script.
> 2) Furthermore, the number-of-input-verification and the
> outputhash-verification operations ought to be split into different opcodes
> as they are logically unrelated.
> 3) Better still, we should instead implement the transaction reflection
> operations of OP_PUSHOUTPUTHASH and OP_NUMINPUTS that puts the outputhash
> and number of inputs respectively onto the stack.  Recursive covenants
> appear to be effectively impossible without either an OP_TWEEKPUBKEY or an
> OP_PUSHSCRIPTPUBKEY so the effort your proposal goes through to guard
> against placing an arbitrary outputhash onto the stack appears to be wasted
> effort to me.
> 4) If we anticipate adding OP_CHECKSIGFROMSTACKVERIFY, then we should most
> definitely prefer (3) instead of OP_COSHV, if we still feel the need to do
> anything at all.  It is probably best to have both
> OP_CHECKSIGFROMSTACKVERIFY and transaction reflection operations of
> OP_PUSHOUTPUTHASH and OP_NUMINPUTS but I think I would be fine with just
> OP_CHECKSIGFROMSTACKVERIFY as well.
>
> On the other hand, if we are serious about preferring less per-block
> bandwidth over reusable primitive opcodes for programming, then we should
> instead abandon the RISC-style Bitcoin Script and instead add an
> alternative CISC-style taproot leaf type that directly provides (a
> conjunction of) the various popular common policies: channel opening,
> channel factories, coinjoins, hashlocks, timelocks, congestion control
> etc.  Segwit v0 already implements this CISC-style for the single most
> popular policy: single signature verification.
>
> On Fri, May 24, 2019 at 4:51 PM Jeremy <jlrubin@mit.edu> wrote:
>
>> Hi Russell,
>>
>> Thanks for this detailed comparison. The COSHV BIP does include a brief
>> comparison to OP_CHECKSIGFROMSTACKVERIFY and ANYPREVOUT, but this is more
>> detailed.
>>
>>
>> I think that the power from CHECKSIGFROMSTACKVERIFY is awesome. It's
>> clearly one of the more flexible options available and would enable a
>> multitude of new use cases.
>>
>> When I originally presented my work on congestion control at Jan 2017
>> BPASE, I also discussed it as an option for covenants. Unfortunately I
>> think it may be on the edge of too powerful -- there are a lot of use cases
>> and implications from having a potentially recursive covenant. If you see
>> my response to Matt in the OP_COSHV BIP thread I classify it as enabling a
>> non-computationally enumerable set of restrictions.
>>
>> I think also from a developer point of view working with OP_COSHV is much
>> much simpler (maybe this can be abstracted) which will lead to increased
>> adoption. OP_COSHV also uses less per-block bandwidth which also makes it
>> preferable for a measure intended to decongest blocks. Do you know the
>> exact byte cost for OP_CHECKSIGFROMSTACK? OP_COSHV scripts, with templating
>> changes to taproot, can be a single byte. OP_COSHV also has less potential
>> to have a negative interaction with future opcodes we may want like
>> OP_PUBKEYTWEAK. While we're getting to an exact spec for the features we
>> want in Bitcoin scripting, it's hard to sign on to OP_CHECKSIGFROMSTACK
>> unless there's an exact specification which makes us confident we're
>> hitting all the points.
>>
>> If the main complaint about OP_COSHV is that it peeks at surrounding
>> data, it's also possible to implement it more closely to a multi-byte
>> pushdata opcode or do the template optimization.
>>
>> Lastly, as I have previously noted, OP_LEFT is probably safer to
>> implement than OP_CAT and should be more efficient for OP_CHECKSIGFROMSTACK
>> scripts.
>>
>>

--000000000000fcb08b0589abf2bd
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">What do you think about h=
aving it be OP_CHECK_TXID_TEMPLATE_DATA where the hash checked is the TXID =
of the transaction with the inputs set to 0000... (maybe appended to the fe=
e paid)?</div><div class=3D"gmail_default" style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmai=
l_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:#000000">This allows for a variable number of inputs to be allowed (e=
.g., one, two, etc). This also fixes potential bugs around TXID malleabilit=
y for lightning like setups (Greg and I discussed in wizards about version =
malleability).</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-siz=
e:small;color:#000000">Allowing multiple inputs is great for structuring mo=
re complex contracts with multiple nodes paying into the same covenantted t=
ransaction.<br></div><div class=3D"gmail_default" style=3D"font-family:aria=
l,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000">Also I personally prefer a RISC+CISC approach -- we =
should enable the common paths easily as they are known (didn&#39;t you com=
e up with jets?) and improve security for API users, but also piecemeal ena=
ble features in script to allow for experimentation or custom contracts.<br=
></div><div><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gm=
ail_signature"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/Jeremy=
Rubin" target=3D"_blank">@JeremyRubin</a><a href=3D"https://twitter.com/Jer=
emyRubin" target=3D"_blank"></a></div></div></div><br></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, May 24, 2019=
 at 4:15 PM Russell O&#39;Connor &lt;<a href=3D"mailto:roconnor@blockstream=
.io">roconnor@blockstream.io</a>&gt; wrote:<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex"><div dir=3D"ltr"><div>In order of escalating sc=
ope of amendments to OP_COSHV, I suggest<br></div><div><br></div><div>1) Pe=
eking at surrounding data surrounding data should definitely be replaced by=
 a pushdata-like op-code that uses the subsequent 32-bytes directly.=C2=A0 =
The OP_SUCCESSx upgrade path specifically allows for this, and avoids compl=
icating the semantics Bitcoin Script.<br></div><div>2) Furthermore, the num=
ber-of-input-verification and the outputhash-verification operations ought =
to be split into different opcodes as they are logically unrelated.<br></di=
v><div>3) Better still, we should instead implement the transaction reflect=
ion operations of OP_PUSHOUTPUTHASH and OP_NUMINPUTS that puts the outputha=
sh and number of inputs respectively onto the stack.=C2=A0 Recursive covena=
nts appear to be effectively impossible without either an OP_TWEEKPUBKEY or=
 an OP_PUSHSCRIPTPUBKEY so the effort your proposal goes through to guard a=
gainst placing an arbitrary outputhash onto the stack appears to be wasted =
effort to me.<br></div><div>4) If we anticipate adding OP_CHECKSIGFROMSTACK=
VERIFY, then we should most definitely prefer (3) instead of OP_COSHV, if w=
e still feel the need to do anything at all.=C2=A0 It is probably best to h=
ave both OP_CHECKSIGFROMSTACKVERIFY and transaction reflection operations o=
f OP_PUSHOUTPUTHASH and OP_NUMINPUTS but I think I would be fine with just =
OP_CHECKSIGFROMSTACKVERIFY as well.<br></div><div><br></div><div>On the oth=
er hand, if we are serious about preferring less per-block bandwidth over r=
eusable primitive opcodes for programming, then we should instead abandon t=
he RISC-style Bitcoin Script and instead add an alternative CISC-style tapr=
oot leaf type that directly provides (a conjunction of) the various popular=
 common policies: channel opening, channel factories, coinjoins, hashlocks,=
 timelocks, congestion control etc.=C2=A0 Segwit v0 already implements this=
 CISC-style for the single most popular policy: single signature verificati=
on.<br></div><div><br></div><div class=3D"gmail_quote"><div dir=3D"ltr" cla=
ss=3D"gmail_attr">On Fri, May 24, 2019 at 4:51 PM Jeremy &lt;<a href=3D"mai=
lto:jlrubin@mit.edu" target=3D"_blank">jlrubin@mit.edu</a>&gt; wrote:<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div=
 style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(=
0,0,0)">Hi Russell,</div><div style=3D"font-family:arial,helvetica,sans-ser=
if;font-size:small;color:rgb(0,0,0)"><br></div><div style=3D"font-family:ar=
ial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Thanks for this =
detailed comparison. The COSHV BIP does include a brief comparison to OP_CH=
ECKSIGFROMSTACKVERIFY and ANYPREVOUT, but this is more detailed.</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,helv=
etica,sans-serif;font-size:small;color:rgb(0,0,0)">I think that the power f=
rom CHECKSIGFROMSTACKVERIFY is awesome. It&#39;s clearly one of the more fl=
exible options available and would enable a multitude of new use cases.</di=
v><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;colo=
r:rgb(0,0,0)"><br></div><div style=3D"font-family:arial,helvetica,sans-seri=
f;font-size:small;color:rgb(0,0,0)">When I originally presented my work on =
congestion control at Jan 2017 BPASE, I also discussed it as an option for =
covenants. Unfortunately I think it may be on the edge of too powerful -- t=
here are a lot of use cases and implications from having a potentially recu=
rsive covenant. If you see my response to Matt in the OP_COSHV BIP thread I=
 classify it as enabling a non-computationally enumerable set of restrictio=
ns. <br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:rgb(0,0,0)"><br></div><div style=3D"font-family:arial,helveti=
ca,sans-serif;font-size:small;color:rgb(0,0,0)">I think also from a develop=
er point of view working with OP_COSHV is much much simpler (maybe this can=
 be abstracted) which will lead to increased adoption. OP_COSHV also uses l=
ess per-block bandwidth which also makes it preferable for a measure intend=
ed to decongest blocks. Do you know the exact byte cost for OP_CHECKSIGFROM=
STACK? OP_COSHV scripts, with templating changes to taproot, can be a singl=
e byte. OP_COSHV also has less potential to have a negative interaction wit=
h future opcodes we may want like OP_PUBKEYTWEAK. While we&#39;re getting t=
o an exact spec for the features we want in Bitcoin scripting, it&#39;s har=
d to sign on to OP_CHECKSIGFROMSTACK unless there&#39;s an exact specificat=
ion which makes us confident we&#39;re hitting all the points.<br></div><di=
v 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;fon=
t-size:small;color:rgb(0,0,0)">If the main complaint about OP_COSHV is that=
 it peeks at surrounding data, it&#39;s also possible to implement it more =
closely to a multi-byte pushdata opcode or do the template optimization.</d=
iv><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;col=
or:rgb(0,0,0)"><br></div><div style=3D"font-family:arial,helvetica,sans-ser=
if;font-size:small;color:rgb(0,0,0)">Lastly, as I have previously noted, OP=
_LEFT is probably safer to implement than OP_CAT and should be more efficie=
nt for OP_CHECKSIGFROMSTACK scripts.<br></div><br></div>
</blockquote></div></div>
</blockquote></div>

--000000000000fcb08b0589abf2bd--