path: root/78/29bd3f85145fb4000be1493d9b8d0667cdca87

Return-Path: <roconnor@blockstream.io>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id BCF61DB1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 25 May 2019 12:52:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it1-f181.google.com (mail-it1-f181.google.com
	[209.85.166.181])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A6F4F6C5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 25 May 2019 12:52:56 +0000 (UTC)
Received: by mail-it1-f181.google.com with SMTP id j17so13251070itk.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 25 May 2019 05:52:56 -0700 (PDT)
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
	:cc; bh=gR6A/nkdx9nCGMyn1we4ycoC4TKsf2ayGr+BzW71Xyk=;
	b=qpbtrkNWnPGWILI0wgmaDB/p8pZC4HxNa4JRnq49QfmA8hRyPlKyr/SrxWKD/2XFQO
	9F8GZgayolSUMumB8EMZJe9KB4Tz03xV+OlfbCObMJXXlTk1Izr9ACGox5643B44NL3F
	8fpR4bzhBQF//LpTYkcNOYCLEFbvih/84U6rs=
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:cc;
	bh=gR6A/nkdx9nCGMyn1we4ycoC4TKsf2ayGr+BzW71Xyk=;
	b=qW0TlEQgLUO4BK2Sie1Hhce4CT70YA9+TFP+obVqmVsCklHyWNXECh7OZNbUuoaPpu
	47IrRdjyOTX6jF7Gsfpecf5ht++jMtxB9LKinVl6gkj5rhrZDpz5I3Ic1fvOnqnfyXsz
	zG9jZ7ZXIK3Cq6QoYxgzc7fXNWJv9NjHcMGEmOUgqy/OgzSy88gJTO/yuZpXo9Q2IArR
	dm5o8JuwPfpnGceKwm/EKpbqDVweM+gIl5d4ena1PZmCKiteOX2+Bj1n0ApTOlQc4Voy
	U+rQaF6XZpbiClTPNVeG4XLdlQ/QDwUXkHUmxdQn97iLBkcVlvFcpAwU4+28yq9WgEXN
	GVZw==
X-Gm-Message-State: APjAAAV4FA23VxJvqPBy8I7SE0pK2SDgGKLfAo+Tkcz6dTU1+G8KQB3Y
	iI/G6fQOrPDrBVH+eKa5O29XseSgvDhCXZbX9VRQkxlGsXg=
X-Google-Smtp-Source: APXvYqy4guTXTDuMJ61z1PF0x2QpooFhe7wq2mByeq8G3NwkRjkQOvRAXWN1ENlktmd7RjtacsrRdwk8s+Kj1h1FNL0=
X-Received: by 2002:a02:7420:: with SMTP id o32mr2118049jac.117.1558788775753; 
	Sat, 25 May 2019 05:52:55 -0700 (PDT)
MIME-Version: 1.0
References: <CAMZUoK=0YhqxguphmaKsMGZCy_NYVE_i53qGBfPVES=GAYTy1g@mail.gmail.com>
	<CAD5xwhgVeTPP23SLrMrvXe6ApZyuuQq4us5z7wrPeJkx1+FSYA@mail.gmail.com>
	<CAMZUoKkA4UFivR4xpFcSRE6ThtYawXh9M8my1HnKv34i4o6FJw@mail.gmail.com>
	<CAD5xwhi9YoJ30xOo++mxqLeeGV7gy5kkucUSGzPJ9BkVVKxbfg@mail.gmail.com>
In-Reply-To: <CAD5xwhi9YoJ30xOo++mxqLeeGV7gy5kkucUSGzPJ9BkVVKxbfg@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Sat, 25 May 2019 08:52:44 -0400
Message-ID: <CAMZUoKmxxS9fDd8ZA0gvFe+q_W=Pwh+6LzZ1bZXxOh4iPmxD1Q@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>
Content-Type: multipart/alternative; boundary="00000000000042523b0589b5cbcd"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE 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: Sun, 26 May 2019 14:05:37 +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 12:52:57 -0000

--00000000000042523b0589b5cbcd
Content-Type: text/plain; charset="UTF-8"

Allowing multiple inputs is certainly better than the 1 restriction COSHV.

However, I agree on your preference for a RISC+CISC approach.  Which is why
instead of COSHV or CHECK_TXID_TEMPLACE_DATA we should do the more RISC-y
thing and begin adding transaction reflection primitives, starting with
OP_NUMINPUTS and OP_PUSHOUTPUTSHASH.  Nothing bad will happen by pushing
the OUTPUTSHASH onto the stack, and we won't even get recursive covenants
with just these transaction reflection primitives in tapscript.

On Fri, May 24, 2019 at 9:08 PM Jeremy <jlrubin@mit.edu> wrote:

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

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

<div dir=3D"ltr"><div>Allowing multiple inputs is certainly better than the=
 1 restriction COSHV.</div><div><br></div><div>However, I agree on your pre=
ference for a RISC+CISC approach.=C2=A0 Which is why instead of COSHV or CH=
ECK_TXID_TEMPLACE_DATA we should do the more RISC-y thing and begin adding =
transaction reflection primitives, starting with OP_NUMINPUTS and OP_PUSHOU=
TPUTSHASH.=C2=A0 Nothing bad will happen by pushing the OUTPUTSHASH onto th=
e stack, and we won&#39;t even get recursive covenants with just these tran=
saction reflection primitives  in tapscript.</div><div class=3D"gmail_quote=
"><div dir=3D"ltr" class=3D"gmail_attr"><br></div><div dir=3D"ltr" class=3D=
"gmail_attr">On Fri, May 24, 2019 at 9:08 PM Jeremy &lt;<a href=3D"mailto:j=
lrubin@mit.edu">jlrubin@mit.edu</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(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)">What do you t=
hink 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 append=
ed to the fee paid)?</div><div style=3D"font-family:arial,helvetica,sans-se=
rif;font-size:small;color:rgb(0,0,0)"><br></div><div style=3D"font-family:a=
rial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">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 (G=
reg and I discussed in wizards about version malleability).</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)">Allowing multiple inputs is great for structuring m=
ore complex contracts with multiple nodes paying into the same covenantted =
transaction.<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)">Also I personally p=
refer a RISC+CISC approach -- we should enable the common paths easily as t=
hey are known (didn&#39;t you come up with jets?) and improve security for =
API users, but also piecemeal enable features in script to allow for experi=
mentation or custom contracts.<br></div><div><div dir=3D"ltr" class=3D"gmai=
l-m_3830482327225069322gmail_signature"><div dir=3D"ltr">--<br><a href=3D"h=
ttps://twitter.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a href=
=3D"https://twitter.com/JeremyRubin" target=3D"_blank"></a></div></div></di=
v><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"m=
ailto:roconnor@blockstream.io" target=3D"_blank">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(204,204,204);padding-left:1ex"><di=
v dir=3D"ltr"><div>In order of escalating scope of amendments to OP_COSHV, =
I suggest<br></div><div><br></div><div>1) Peeking at surrounding data surro=
unding data should definitely be replaced by a pushdata-like op-code that u=
ses the subsequent 32-bytes directly.=C2=A0 The OP_SUCCESSx upgrade path sp=
ecifically allows for this, and avoids complicating the semantics Bitcoin S=
cript.<br></div><div>2) Furthermore, the number-of-input-verification and t=
he outputhash-verification operations ought to be split into different opco=
des as they are logically unrelated.<br></div><div>3) Better still, we shou=
ld instead implement the transaction reflection operations of OP_PUSHOUTPUT=
HASH and OP_NUMINPUTS that puts the outputhash and number of inputs respect=
ively onto the stack.=C2=A0 Recursive covenants appear to be effectively im=
possible without either an OP_TWEEKPUBKEY or an OP_PUSHSCRIPTPUBKEY so the =
effort your proposal goes through to guard against placing an arbitrary out=
puthash onto the stack appears to be wasted effort to me.<br></div><div>4) =
If we anticipate adding OP_CHECKSIGFROMSTACKVERIFY, then we should most def=
initely prefer (3) instead of OP_COSHV, if we still feel the need to do any=
thing at all.=C2=A0 It is probably best to have both OP_CHECKSIGFROMSTACKVE=
RIFY and transaction reflection operations of OP_PUSHOUTPUTHASH and OP_NUMI=
NPUTS but I think I would be fine with just OP_CHECKSIGFROMSTACKVERIFY as w=
ell.<br></div><div><br></div><div>On the other hand, if we are serious abou=
t preferring less per-block bandwidth over reusable primitive opcodes for p=
rogramming, then we should instead abandon the RISC-style Bitcoin Script an=
d instead add an alternative CISC-style taproot leaf type that directly pro=
vides (a conjunction of) the various popular common policies: channel openi=
ng, 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 verification.<br></div><div><br></div><di=
v class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, May 2=
4, 2019 at 4:51 PM Jeremy &lt;<a href=3D"mailto: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;border-left:1px solid rgb(204,204,=
204);padding-left:1ex"><div dir=3D"ltr"><div style=3D"font-family:arial,hel=
vetica,sans-serif;font-size:small;color:rgb(0,0,0)">Hi Russell,</div><div s=
tyle=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-s=
ize:small;color:rgb(0,0,0)">Thanks for this detailed comparison. The COSHV =
BIP does include a brief comparison to OP_CHECKSIGFROMSTACKVERIFY and ANYPR=
EVOUT, but this is more detailed.</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)"><b=
r></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:smal=
l;color:rgb(0,0,0)">I think that the power from CHECKSIGFROMSTACKVERIFY is =
awesome. It&#39;s clearly one of the more flexible options available and wo=
uld enable a multitude of new use cases.</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)">When I originally presented my work on congestion control at Jan 2017 =
BPASE, I also discussed it as an option for covenants. Unfortunately I thin=
k 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 r=
esponse to Matt in the OP_COSHV BIP thread I classify it as enabling a non-=
computationally enumerable set of restrictions. <br></div><div style=3D"fon=
t-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;c=
olor:rgb(0,0,0)">I think also from a developer point of view working with O=
P_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 a=
lso makes it preferable for a measure intended to decongest blocks. Do you =
know the exact byte cost for OP_CHECKSIGFROMSTACK? OP_COSHV scripts, with t=
emplating 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 li=
ke OP_PUBKEYTWEAK. While we&#39;re getting to an exact spec for the feature=
s we want in Bitcoin scripting, it&#39;s hard to sign on to OP_CHECKSIGFROM=
STACK unless there&#39;s an exact specification which makes us confident we=
&#39;re hitting all the points.<br></div><div style=3D"font-family:arial,he=
lvetica,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)=
">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 pushd=
ata opcode or do the template optimization.</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)">Lastly, as I have previously noted, OP_LEFT is probably safer to im=
plement than OP_CAT and should be more efficient for OP_CHECKSIGFROMSTACK s=
cripts.<br></div><br></div>
</blockquote></div></div>
</blockquote></div>
</blockquote></div></div>

--00000000000042523b0589b5cbcd--