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
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
|
Return-Path: <danrobinson010@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 9C7F49C
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 3 Nov 2016 07:37:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f180.google.com (mail-qk0-f180.google.com
[209.85.220.180])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C69D78E
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 3 Nov 2016 07:37:41 +0000 (UTC)
Received: by mail-qk0-f180.google.com with SMTP id x190so45127191qkb.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 03 Nov 2016 00:37:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=+E20lkAOjFBhk8eWz6ESpVnHL0N0cM4eVd2nwOD9WeA=;
b=EHl7RFH+oAUH9V47p305eKYIy0bQnCPgIUaLeTd1tGHp4fueHx7cCj3oUE51H5v82P
G5hrZQXf8scd7kQFwxnuLKyF0Io2YKbnNqD5g0ulLI2dBix+IGe4PngF9WrbGGVCe2Cn
05uFFUSp416DdfQQJyL70/eadtpfczreZ9OAUTh2zsrCzYxaLi2PZYv0vNzpoMxwYSYI
AEWjzUqcn8PZXWrFh243dP3kDTD3zf/OLiU2yQxyDU38e/HHdb+j6a13nvPiuHNX9kaC
/w2IotR7hrGz0PwvePevFPeOmmfQRFj5Dfqe7J0EXeFi0ZIYA820tzLhb919a2WO/a5K
bSEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to;
bh=+E20lkAOjFBhk8eWz6ESpVnHL0N0cM4eVd2nwOD9WeA=;
b=gr8StVyDob6x5JHWRP1Nt01HRfF+pUrzMhC0LsOB40xtZefc5CoJkXEjquGSgsW/71
yRD84pB02eCgoZdN9wvNCGy23g4p85kUQdD4VI7c+odHkVjUSogjKf2ZCPWABwhknbqb
JUCMFJeJ7qQrdk7EmMgiKbFPaUaAyLSODGT36ZzxXv9G8P+ohnKQwys+WM+kPvvXBhuN
HfJmlCg2zZIaVypLO4TlaTkWkVkP5n2wl7IjiaHcSrZvUymCLjcb71OoFoJCcDCrbgNe
zI1cUVtzmrep1b6UZOE83TPcZE7GW139qgqlHCOMKlMBgseW5u6PB4ljVSN/wbklGZzc
AuVQ==
X-Gm-Message-State: ABUngveU9jM0FbtCmTsgLC3ZaZ0jv/OZmAXRnHIbrsarbgnVrI1xGpBZy+81BUG0QG/pAz863RwXBeMnc14mbA==
X-Received: by 10.55.68.80 with SMTP id r77mr7236181qka.318.1478158660986;
Thu, 03 Nov 2016 00:37:40 -0700 (PDT)
MIME-Version: 1.0
References: <CAMZUoKkG0AqwsTE=opTcsD=xqWsoVxqPVCzFbcSz8zJT1wiFPg@mail.gmail.com>
<E8BB95A5-09B3-443C-B197-29DA3C4767D8@xbt.hk>
<CAMZUoKmnkk=q7GkkvA+Q4-r64JCQ+kPRPdoEN8bnAwd2YGMH+Q@mail.gmail.com>
In-Reply-To: <CAMZUoKmnkk=q7GkkvA+Q4-r64JCQ+kPRPdoEN8bnAwd2YGMH+Q@mail.gmail.com>
From: Daniel Robinson <danrobinson010@gmail.com>
Date: Thu, 03 Nov 2016 07:37:29 +0000
Message-ID: <CAD438HsZRZcRWu=++3kuvyA5Ns9cU360utJMCyc6bROT-fdcHg@mail.gmail.com>
To: "Russell O'Connor" <roconnor@blockstream.io>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Johnson Lau <jl2012@xbt.hk>
Content-Type: multipart/alternative; boundary=001a11489cfce8ee68054060a101
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
HTML_MESSAGE, RCVD_IN_DNSWL_LOW,
RCVD_IN_SORBS_SPAM 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: Thu, 03 Nov 2016 07:55:11 +0000
Subject: Re: [bitcoin-dev] Implementing Covenants with
OP_CHECKSIGFROMSTACKVERIFY
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: Thu, 03 Nov 2016 07:37:42 -0000
--001a11489cfce8ee68054060a101
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Really cool!
How about "poison transactions," the other covenants use case proposed by
M=C3=B6ser, Eyal, and Sirer? (I think OP_CHECKSIGFROMSTACKVERIFY will also =
make
it easier to check fraud proofs, the other prerequisite for poison
transactions.)
Seems a little wasteful to do those two "unnecessary" signature checks, and
to have to construct the entire transaction data structure, just to verify
a single output in the transaction. Any plans to add more flexible
introspection opcodes to Elements, such as OP_CHECKOUTPUTVERIFY?
Really minor nit: "Notice that we have appended 0x83 to the end of the
transaction data"=E2=80=94should this say "to the end of the signature"?
On Thu, Nov 3, 2016 at 12:28 AM Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
Right. There are minor trade-offs to be made with regards to that design
point of OP_CHECKSIGFROMSTACKVERIFY. Fortunately this covenant
construction isn't sensitive to that choice and can be made to work with
either implementation of OP_CHECKSIGFROMSTACKVERIFY.
On Wed, Nov 2, 2016 at 11:35 PM, Johnson Lau <jl2012@xbt.hk> wrote:
Interesting. I have implemented OP_CHECKSIGFROMSTACKVERIFY in a different
way from the Elements. Instead of hashing the data on stack, I directly put
the 32 byte hash to the stack. This should be more flexible as not every
system are using double-SHA256
https://github.com/jl2012/bitcoin/commits/mast_v3_master
On 3 Nov 2016, at 01:30, Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
Hi all,
It is possible to implement covenants using two script extensions: OP_CAT
and OP_CHECKSIGFROMSTACKVERIFY. Both of these op codes are already
available in the Elements Alpha sidechain, so it is possible to construct
covenants in Elements Alpha today. I have detailed how the construction
works in a blog post at <
https://blockstream.com/2016/11/02/covenants-in-elements-alpha.html>. As
an example, I've constructed scripts for the Moeser-Eyal-Sirer vault.
I'm interested in collecting and implementing other useful covenants, so if
people have ideas, please post them.
If there are any questions, I'd be happy to answer.
--=20
Russell O'Connor
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--001a11489cfce8ee68054060a101
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr" class=3D"gmail_msg"><div dir=3D"ltr" clas=
s=3D"gmail_msg">Really cool!<div class=3D"gmail_msg"><br></div><div class=
=3D"gmail_msg">How about "poison transactions," the other covenan=
ts use case proposed by M=C3=B6ser, Eyal, and Sirer? (I think OP_CHECKSIGFR=
OMSTACKVERIFY will also make it easier to check fraud proofs, the other pre=
requisite for poison transactions.)</div><div class=3D"gmail_msg"><br></div=
><div class=3D"gmail_msg">Seems a little wasteful to do those two "unn=
ecessary" signature checks, and to have to construct the entire transa=
ction data structure, just to verify a single output in the transaction. An=
y plans to add more flexible introspection opcodes to Elements, such as OP_=
CHECKOUTPUTVERIFY?</div><div class=3D"gmail_msg"><br class=3D"gmail_msg"></=
div><div class=3D"gmail_msg">Really minor nit: "Notice that we have ap=
pended 0x83 to the end of the transaction data"=E2=80=94should this sa=
y "to the end of the signature"?<br class=3D"gmail_msg"></div></d=
iv></div><div dir=3D"ltr" class=3D"gmail_msg"><br class=3D"gmail_msg"><div =
class=3D"gmail_quote gmail_msg"><div dir=3D"ltr" class=3D"gmail_msg">On Thu=
, Nov 3, 2016 at 12:28 AM Russell O'Connor via bitcoin-dev <<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" class=3D"gmail_msg" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br class=
=3D"gmail_msg"></div><blockquote class=3D"gmail_quote gmail_msg" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr" class=3D"gmail_msg">Right.=C2=A0 There are minor trade-offs to be made =
with regards to that design point of OP_CHECKSIGFROMSTACKVERIFY.=C2=A0 Fort=
unately this covenant construction isn't sensitive to that choice and c=
an be made to work with either implementation of OP_CHECKSIGFROMSTACKVERIFY=
.<br class=3D"gmail_msg"><div class=3D"gmail_msg"><div class=3D"gmail_extra=
gmail_msg"><br class=3D"gmail_msg"><div class=3D"gmail_quote gmail_msg"></=
div></div></div></div><div dir=3D"ltr" class=3D"gmail_msg"><div class=3D"gm=
ail_msg"><div class=3D"gmail_extra gmail_msg"><div class=3D"gmail_quote gma=
il_msg">On Wed, Nov 2, 2016 at 11:35 PM, Johnson Lau <span dir=3D"ltr" clas=
s=3D"gmail_msg"><<a href=3D"mailto:jl2012@xbt.hk" class=3D"gmail_msg" ta=
rget=3D"_blank">jl2012@xbt.hk</a>></span> wrote:<br class=3D"gmail_msg">=
</div></div></div></div><div dir=3D"ltr" class=3D"gmail_msg"><div class=3D"=
gmail_msg"><div class=3D"gmail_extra gmail_msg"><div class=3D"gmail_quote g=
mail_msg"><blockquote class=3D"gmail_quote gmail_msg" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div =
class=3D"gmail_msg"><div class=3D"gmail_msg">Interesting. I have implemente=
d=C2=A0OP_CHECKSIGFROMSTACKVERIFY in a different way from the Elements. Ins=
tead of hashing the data on stack, I directly put the 32 byte hash to the s=
tack. This should be more flexible as not every system are using double-SHA=
256</div><div class=3D"gmail_msg"><br class=3D"gmail_msg"></div><div class=
=3D"gmail_msg"><a href=3D"https://github.com/jl2012/bitcoin/commits/mast_v3=
_master" class=3D"gmail_msg" target=3D"_blank">https://github.com/jl2012/bi=
tcoin/commits/mast_v3_master</a></div><div class=3D"gmail_msg"><br class=3D=
"gmail_msg"></div><br class=3D"gmail_msg"></div></blockquote></div></div></=
div></div><div dir=3D"ltr" class=3D"gmail_msg"><div class=3D"gmail_msg"><di=
v class=3D"gmail_extra gmail_msg"><div class=3D"gmail_quote gmail_msg"><blo=
ckquote class=3D"gmail_quote gmail_msg" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=3D"gmail=
_msg"><div class=3D"gmail_msg"><blockquote type=3D"cite" class=3D"gmail_msg=
"><div class=3D"gmail_msg"><div class=3D"m_-397412428199096019m_31971820458=
85502035m_-5625504829381071238gmail-h5 gmail_msg"><div class=3D"gmail_msg">=
On 3 Nov 2016, at 01:30, Russell O'Connor via bitcoin-dev <<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" class=3D"gmail_msg" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:</div><br =
class=3D"m_-397412428199096019m_3197182045885502035m_-5625504829381071238gm=
ail-m_3266083758070358714Apple-interchange-newline gmail_msg"></div></div><=
/blockquote></div></div></blockquote></div></div></div></div><div dir=3D"lt=
r" class=3D"gmail_msg"><div class=3D"gmail_msg"><div class=3D"gmail_extra g=
mail_msg"><div class=3D"gmail_quote gmail_msg"><blockquote class=3D"gmail_q=
uote gmail_msg" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb=
(204,204,204);padding-left:1ex"><div class=3D"gmail_msg"><div class=3D"gmai=
l_msg"><blockquote type=3D"cite" class=3D"gmail_msg"><div class=3D"gmail_ms=
g"><div class=3D"gmail_msg"><div class=3D"m_-397412428199096019m_3197182045=
885502035m_-5625504829381071238gmail-h5 gmail_msg"><div dir=3D"ltr" class=
=3D"gmail_msg">Hi all,<br class=3D"gmail_msg"><br class=3D"gmail_msg">It is=
possible to implement covenants using two script extensions: OP_CAT and OP=
_CHECKSIGFROMSTACKVERIFY.=C2=A0 Both of these op codes are already availabl=
e in the Elements Alpha sidechain, so it is possible to construct covenants=
in Elements Alpha today.=C2=A0 I have detailed how the construction works =
in a blog post at <<a href=3D"https://blockstream.com/2016/11/02/covenan=
ts-in-elements-alpha.html" class=3D"gmail_msg" target=3D"_blank">https://bl=
ockstream.com/2016/11/02/covenants-in-elements-alpha.html</a>>.=C2=A0 As=
an example, I've constructed scripts for the Moeser-Eyal-Sirer vault.<=
br class=3D"gmail_msg"><br class=3D"gmail_msg">I'm interested in collec=
ting and implementing other useful covenants, so if people have ideas, plea=
se post them.<br class=3D"gmail_msg"><br class=3D"gmail_msg">If there are a=
ny questions, I'd be happy to answer.=C2=A0 <br class=3D"gmail_msg"><br=
class=3D"gmail_msg">-- <br class=3D"gmail_msg">Russell O'Connor<br cla=
ss=3D"gmail_msg"></div></div></div>
_______________________________________________<br class=3D"gmail_msg">bitc=
oin-dev mailing list<br class=3D"gmail_msg"><a href=3D"mailto:bitcoin-dev@l=
ists.linuxfoundation.org" class=3D"gmail_msg" target=3D"_blank">bitcoin-dev=
@lists.linuxfoundation.org</a><br class=3D"gmail_msg"><a href=3D"https://li=
sts.linuxfoundation.org/mailman/listinfo/bitcoin-dev" class=3D"gmail_msg" t=
arget=3D"_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin=
-dev</a><br class=3D"gmail_msg"></div></blockquote></div></div></blockquote=
></div></div></div></div>
_______________________________________________<br class=3D"gmail_msg">
bitcoin-dev mailing list<br class=3D"gmail_msg">
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" class=3D"gmail_msg=
" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br class=3D"g=
mail_msg">
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" class=3D"gmail_msg" target=3D"_blank">https://lists.linu=
xfoundation.org/mailman/listinfo/bitcoin-dev</a><br class=3D"gmail_msg">
</blockquote></div></div></div>
--001a11489cfce8ee68054060a101--
|
