1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
|
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 733E9109B
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 May 2019 20:51:36 +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 DA1FBF4
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 May 2019 20:51:35 +0000 (UTC)
Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com
[209.85.208.43]) (authenticated bits=0)
(User authenticated as jlrubin@ATHENA.MIT.EDU)
by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x4OKpXrv015411
(version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 May 2019 16:51:34 -0400
Received: by mail-ed1-f43.google.com with SMTP id w33so12656627edb.10
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 May 2019 13:51:34 -0700 (PDT)
X-Gm-Message-State: APjAAAVBOGMXAH3+J5LvhuY6DYZtXy2QNnGGUtOpGOK1l/kUF1eCXpfy
Hn0DRdOrvcj1MYEmvDDuLRSltXvU7FD7RiAVtzg=
X-Google-Smtp-Source: APXvYqzlfzG/l4fuHbHq7QGP17t4TtSGNb+Z5fJF3OLB7Qp5QbU0gClX8OoI06ExeHzZLXSNk5q0TaSeflur+lyB1rc=
X-Received: by 2002:a50:84e7:: with SMTP id 94mr105817644edq.137.1558731092954;
Fri, 24 May 2019 13:51:32 -0700 (PDT)
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
X-Gmail-Original-Message-ID: <CAD5xwhgVeTPP23SLrMrvXe6ApZyuuQq4us5z7wrPeJkx1+FSYA@mail.gmail.com>
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"
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
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 20:51:36 -0000
--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'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're getting to an exact spec for the features we w=
ant in Bitcoin scripting, it's hard to sign on to OP_CHECKSIGFROMSTACK =
unless there's an exact specification which makes us confident we'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'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--
|
