path: root/6f/90ab9d7016b52867d7fff2c290ddfd0eee7d1f

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 C251BE51
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 24 May 2019 23:07:41 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it1-f180.google.com (mail-it1-f180.google.com
	[209.85.166.180])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F14666C5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 24 May 2019 23:07:40 +0000 (UTC)
Received: by mail-it1-f180.google.com with SMTP id h20so18429687itk.4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 24 May 2019 16:07:40 -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=TWpDAx7x56lZ4/SC0JdA2vm10xqInTUW334DjUwLfQc=;
	b=rHURuX2/G72CZfH1QoNIoE0yTPBOfb2alOZarPF9K8FvwBMHu263t3jeCWFXtARCuC
	WJruhIjR8PNH+KJNNNzfckUwucXUitOeEOQQ4KFLP1kkLopDfhHERLiAxgJ9V5fcK6/p
	aTxgnaW0N+tBOroS1qtT5ogO+7CaLbHWoc1Yc=
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=TWpDAx7x56lZ4/SC0JdA2vm10xqInTUW334DjUwLfQc=;
	b=PBOQvmNovz4FHGIBn9wpysz1Xx/bazyTqqFUrypE5L86MBjdJZkbhQHsr2auIwq9NZ
	QnsM24It9I1wioUGBkaPPWpeWkEQc0d58/myQktbWVLS+yKOngKemB4sjGnhTKL4xD72
	L8zsY7zDWUVf3QRK1sJcS58C/sBpy01gWmFAOyGfibI2ebqU4OTqmD+JspUKQZjeQ1IS
	kZKFTkkmncZ1w39oRXaNEEDf0B9qikkhyZ8NA8y5rO2Y2lIIf+kpIgqTbrYCBNMAqb8n
	MJ9Qca1IKPSoUApDWiIBeEjGhcWdddxCL3nfRTTdZpjIXzGXnCp15mZrMnNJ+Sf+mYLf
	tllg==
X-Gm-Message-State: APjAAAVZltpRIjB0MGA5mC17RoOwxf8B6AHDc7KUWEjv0qswbY7/H5we
	ibt4RCyjot563Y4/bkxVOdb1WXfdpDCakYm6ff61DQ==
X-Google-Smtp-Source: APXvYqwLJhNCWEanXhsGYuCH/PxcQ8+MzoKJCFtvZGkB0TWXuHVFoiieH+5PqY+l144sQR7pYRCZxOtnX9y0Ho2yrwg=
X-Received: by 2002:a05:660c:50:: with SMTP id
	p16mr19142420itk.146.1558739260222; 
	Fri, 24 May 2019 16:07:40 -0700 (PDT)
MIME-Version: 1.0
References: <CAMZUoK=0YhqxguphmaKsMGZCy_NYVE_i53qGBfPVES=GAYTy1g@mail.gmail.com>
	<CAD5xwhgVeTPP23SLrMrvXe6ApZyuuQq4us5z7wrPeJkx1+FSYA@mail.gmail.com>
In-Reply-To: <CAD5xwhgVeTPP23SLrMrvXe6ApZyuuQq4us5z7wrPeJkx1+FSYA@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Fri, 24 May 2019 19:07:28 -0400
Message-ID: <CAMZUoKkA4UFivR4xpFcSRE6ThtYawXh9M8my1HnKv34i4o6FJw@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>
Content-Type: multipart/alternative; boundary="000000000000e7417c0589aa43f2"
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: Sat, 25 May 2019 12:05:39 +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: Fri, 24 May 2019 23:07:41 -0000

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

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

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

<div dir=3D"ltr"><div>In order of escalating scope of amendments to OP_COSH=
V, I suggest<br></div><div><br></div><div>1) Peeking at surrounding data su=
rrounding data should definitely be replaced by a pushdata-like op-code tha=
t uses the subsequent 32-bytes directly.=C2=A0 The OP_SUCCESSx upgrade path=
 specifically allows for this, and avoids complicating the semantics Bitcoi=
n Script.<br></div><div>2) Furthermore, the number-of-input-verification an=
d the outputhash-verification operations ought to be split into different o=
pcodes as they are logically unrelated.<br></div><div>3) Better still, we s=
hould instead implement the transaction reflection operations of OP_PUSHOUT=
PUTHASH and OP_NUMINPUTS that puts the outputhash and number of inputs resp=
ectively onto the stack.=C2=A0 Recursive covenants appear to be effectively=
 impossible without either an OP_TWEEKPUBKEY or an OP_PUSHSCRIPTPUBKEY so t=
he effort your proposal goes through to guard against placing an arbitrary =
outputhash onto the stack appears to be wasted effort to me.<br></div><div>=
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.=C2=A0 It is probably best to have both OP_CHECKSIGFROMSTAC=
KVERIFY and transaction reflection operations of OP_PUSHOUTPUTHASH and OP_N=
UMINPUTS but I think I would be fine with just OP_CHECKSIGFROMSTACKVERIFY a=
s well.<br></div><div><br></div><div>On the other hand, if we are serious a=
bout preferring less per-block bandwidth over reusable primitive opcodes fo=
r 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 op=
ening, channel factories, coinjoins, hashlocks, timelocks, congestion contr=
ol etc.=C2=A0 Segwit v0 already implements this CISC-style for the single m=
ost popular policy: single signature verification.<br></div><div><br></div>=
<div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Ma=
y 24, 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"gm=
ail_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=
,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Hi Russell,</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)">Thanks for this detailed comparison. The CO=
SHV BIP does include a brief comparison to OP_CHECKSIGFROMSTACKVERIFY and A=
NYPREVOUT, 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,helvetica,sans-serif;font-size:=
small;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 an=
d would enable a multitude of new use cases.</div><div style=3D"font-family=
:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><di=
v style=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 2=
017 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. <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:sma=
ll;color:rgb(0,0,0)">I think also from a developer point of view working wi=
th 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 whi=
ch also makes it preferable for a measure intended to decongest blocks. Do =
you know the exact byte cost for OP_CHECKSIGFROMSTACK? OP_COSHV scripts, wi=
th templating changes to taproot, can be a single byte. OP_COSHV also has l=
ess potential to have a negative interaction with future opcodes we may wan=
t like OP_PUBKEYTWEAK. While we&#39;re getting to an exact spec for the fea=
tures we want in Bitcoin scripting, it&#39;s hard to sign on to OP_CHECKSIG=
FROMSTACK unless there&#39;s an exact specification which makes us confiden=
t we&#39;re hitting all the points.<br></div><div style=3D"font-family:aria=
l,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div sty=
le=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 da=
ta, it&#39;s also possible to implement it more closely to a multi-byte pus=
hdata opcode or do the template optimization.</div><div style=3D"font-famil=
y:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><d=
iv style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rg=
b(0,0,0)">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.<br></div><br></div>
</blockquote></div></div>

--000000000000e7417c0589aa43f2--