MIME-Version: 1.0
References: <CAMZUoK=0YhqxguphmaKsMGZCy_NYVE_i53qGBfPVES=GAYTy1g@mail.gmail.com>
In-Reply-To: <CAMZUoK=0YhqxguphmaKsMGZCy_NYVE_i53qGBfPVES=GAYTy1g@mail.gmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Fri, 24 May 2019 13:51:21 -0700
Message-ID: <CAD5xwhgVeTPP23SLrMrvXe6ApZyuuQq4us5z7wrPeJkx1+FSYA@mail.gmail.com>
To: "Russell O'Connor" <roconnor@blockstream.io>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000001893750589a85dd7"
Subject: Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK
Precedence: list

--0000000000001893750589a85dd7
Content-Type: text/plain; charset="UTF-8"

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.

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

<div dir=3D"ltr"><div style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:rgb(0,0,0)" class=3D"gmail_default">Hi Russell,</div><div =
style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0=
,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default=
">Thanks for this detailed comparison. The COSHV BIP does include a brief c=
omparison to OP_CHECKSIGFROMSTACKVERIFY and ANYPREVOUT, but this is more de=
tailed.</div><div style=3D"font-family:arial,helvetica,sans-serif;font-size=
:small;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"fo=
nt-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" clas=
s=3D"gmail_default"><br></div><div style=3D"font-family:arial,helvetica,san=
s-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">I think t=
hat the power from CHECKSIGFROMSTACKVERIFY is awesome. It&#39;s clearly one=
 of the more flexible options available and 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)" class=3D"gmail_default"><br></div><div style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
" class=3D"gmail_default">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 cove=
nant. 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;co=
lor:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-family=
:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmai=
l_default">I think also from a developer point of view working with OP_COSH=
V is much much simpler (maybe this can be abstracted) which will lead to in=
creased adoption. OP_COSHV also uses less per-block bandwidth which also ma=
kes it preferable for a measure intended to decongest blocks. Do you know t=
he exact byte cost for OP_CHECKSIGFROMSTACK? OP_COSHV scripts, with templat=
ing changes to taproot, can be a single byte. OP_COSHV also has less potent=
ial to have a negative interaction with future opcodes we may want like OP_=
PUBKEYTWEAK. While we&#39;re getting to an exact spec for the features we w=
ant in Bitcoin scripting, it&#39;s hard to sign on to OP_CHECKSIGFROMSTACK =
unless there&#39;s an exact specification which makes us confident we&#39;r=
e hitting all the points.<br></div><div style=3D"font-family:arial,helvetic=
a,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><br>=
</div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:rgb(0,0,0)" class=3D"gmail_default">If the main complaint about OP_CO=
SHV is that it peeks at surrounding data, it&#39;s also possible to impleme=
nt it more closely to a multi-byte pushdata opcode or do the template optim=
ization.</div><div style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" cla=
ss=3D"gmail_default">Lastly, as I have previously noted, OP_LEFT is probabl=
y safer to implement than OP_CAT and should be more efficient for OP_CHECKS=
IGFROMSTACK scripts.<br></div><br></div>

--0000000000001893750589a85dd7--