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
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <flavien.charlon@pixodegames.com>) id 1XqKpX-0001yR-Gu
for bitcoin-development@lists.sourceforge.net;
Mon, 17 Nov 2014 11:50:51 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of
pixodegames.com designates 209.85.217.182 as permitted sender)
client-ip=209.85.217.182;
envelope-from=flavien.charlon@pixodegames.com;
helo=mail-lb0-f182.google.com;
Received: from mail-lb0-f182.google.com ([209.85.217.182])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XqKpV-0002Lv-Fk
for bitcoin-development@lists.sourceforge.net;
Mon, 17 Nov 2014 11:50:51 +0000
Received: by mail-lb0-f182.google.com with SMTP id f15so17469465lbj.13
for <bitcoin-development@lists.sourceforge.net>;
Mon, 17 Nov 2014 03:50:43 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc:content-type;
bh=v5x3qwtzzzSut4U3ACujo2D4fJ3FY9u6KSuXxOU2uA8=;
b=FG+DqAkY4y3qxVOiXE8d0QaYYK2jLrnRwXelkOkMqJlbNLp0AMpDvepgtm4jMRv/Wm
dp/AusIO5V6+Owene+cKGrQaZ2VKuWfJ47IuD7dzT9CE5eRuE1zTLqL/iuEL5txZski8
K+TeKJajDiD4zmW1HlVVuDLpqN5JcyLx0FUBwm0nv5ns6eVeJq4Z6bN9SvIltzbl+YWC
GyniQdqfqsSDD0Z/1OhQGI51GzQbNf5QiCG69XM/QgLrg5Nz3IYLek3RVpM9N9bHCic/
HjWx+I+VfYAoEUed7MP/jMu03ntF8xvHHLMrhv4QmXlp5ciyoDZSTLUjlh7DPyd9sUNp
2FJA==
X-Gm-Message-State: ALoCoQnoCgzaUwIGbMXG+INVHgISqUIsai8DT45iEEkRNjAd90qVRd4vTlaQ+Y8RLwXvOc6UkGWj
X-Received: by 10.152.7.193 with SMTP id l1mr26568749laa.57.1416224658994;
Mon, 17 Nov 2014 03:44:18 -0800 (PST)
Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com.
[209.85.217.171])
by mx.google.com with ESMTPSA id e10sm9026776lbq.1.2014.11.17.03.44.18
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Mon, 17 Nov 2014 03:44:18 -0800 (PST)
Received: by mail-lb0-f171.google.com with SMTP id b6so15888366lbj.30
for <bitcoin-development@lists.sourceforge.net>;
Mon, 17 Nov 2014 03:44:18 -0800 (PST)
X-Received: by 10.152.204.9 with SMTP id ku9mr12427123lac.55.1416224658258;
Mon, 17 Nov 2014 03:44:18 -0800 (PST)
MIME-Version: 1.0
Received: by 10.114.23.227 with HTTP; Mon, 17 Nov 2014 03:43:38 -0800 (PST)
X-Originating-IP: [89.100.161.202]
In-Reply-To: <CAPg+sBgM4ja0Y96KekJUN7Qg=o0xa1B0VUiiPuFQTYfrupoERg@mail.gmail.com>
References: <CABbpET9eTgk1GyxYbcG++O_rqsnfB7w5_Xp4XgE6qwkmGsm1eg@mail.gmail.com>
<201411161724.19573.luke@dashjr.org>
<CABm2gDpBOtZB01Qj3Dc3dWSpG2zLr+VPYbnwrq8YVh8qfxMW5Q@mail.gmail.com>
<CABm2gDoi1593ssoGN69E42c-N3s02yYKAqDEDA2m-e+6LqjpTQ@mail.gmail.com>
<5469692F.9030702@gmail.com>
<CAPg+sBgM4ja0Y96KekJUN7Qg=o0xa1B0VUiiPuFQTYfrupoERg@mail.gmail.com>
From: Flavien Charlon <flavien.charlon@coinprism.com>
Date: Mon, 17 Nov 2014 11:43:38 +0000
Message-ID: <CABbpET8yyZHO185Fzip61KoRTrGy4bEaoEpnzPuARfhhfPUTCg@mail.gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=001a1134386ead97bc05080c7f4e
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1XqKpV-0002Lv-Fk
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload
size
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 17 Nov 2014 11:50:51 -0000
--001a1134386ead97bc05080c7f4e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
> My main concern with OP_RETURN is that it seems to encourage people to
use the blockchain as a convenient transport channel
The number one user of the blockchain as a storage and transport mechanism
is Counterparty, and limiting OP_RETURN to 40 bytes didn't prevent them
from doing so. In fact they use multi-sig outputs which is worse than
OP_RETURN since it's not always prunable, and yet let them store much more
than 40 bytes.
For Open Assets <https://github.com/OpenAssets/open-assets-protocol>, we
need to store a URL in the OP_RETURN output (with optionally a hash) plus
some bytes of overhead. 40 bytes comes really short for that. The benefit
of having a URL in there is that any storage mechanism can be used (Web,
FTP, BitTorrent, MaidSafe...), whereas with only a hash, you have to
hardcode the storing mechanism in the protocol (and even then, a hash is
not enough to address a HTTP or FTP resource). Storing only a hash is fine
for the most basic timestamping application, but it's hardly enough to
build something interesting.
I've counted the number of OP_RETURN outputs in the blockchain for the
month of October 2014. There were 1,674 OP_RETURNs for a span of 4,659
blocks. Assuming they were all 40 bytes (the average is probably less than
half of that), that means an increase of 14.37 bytes per block. Considering
a 1 MB block, that's about 0.0013% of the block used up by OP_RETURN data
in average.
Increasing to 80 bytes will have a negligible impact on bandwidth and
storage requirements, while being extremely useful for many use cases where
a hash only is not enough.
Flavien
On Mon, Nov 17, 2014 at 10:35 AM, Pieter Wuille <pieter.wuille@gmail.com>
wrote:
> On Mon, Nov 17, 2014 at 4:19 AM, Alan Reiner <etotheipi@gmail.com> wrote:
> >
> > On 11/16/2014 02:04 PM, Jorge Tim=C3=B3n wrote:
> >> I remember people asking in #bitcoin-dev "Does anyone know any use
> >> case for greater sizes OP_RETURNs?" and me answering "I do not know of
> >> any use cases that require bigger sizes".
> >
> > For reference, there was a brief time where I was irritated that the
> > size had been reduced to 40 bytes, because I had an application where I
> > wanted to put ECDSA in signatures in the OP_RETURN, and you're going to
> > need at least 64 bytes for that. Unfortunately I can't remember now
> > what that application was, so it's difficult for me to argue for it.
> > But I don't think that's an unreasonable use case: sending a payment
> > with a signature, essentially all timestamped in the blockchain.
>
> You can still send the signature out of band (for example using the
> payment protocol), and just have the transaction commit to a hash of
> that signature (or message in general), either using an OP_RETURN
> output to store the hash, or using the pay-to-contract scheme that
> Jorge mentioned above. That has exactly the same timestamping
> properties.
>
> My main concern with OP_RETURN is that it seems to encourage people to
> use the blockchain as a convenient transport channel, rather than just
> for data that the world needs to see to validate it. I'd rather
> encourage solutions that don't require additional data there, which in
> many cases (but not all) is perfectly possible.
>
> --
> Pieter
>
>
> -------------------------------------------------------------------------=
-----
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=3D157005751&iu=3D/4140/ostg=
.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--001a1134386ead97bc05080c7f4e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>> My main concern with OP_RETURN is that it seems =
to encourage people to use the blockchain as a convenient transport channel=
</div><div><br></div><div>The number one user of the blockchain as a storag=
e and transport mechanism is Counterparty, and limiting OP_RETURN to 40 byt=
es didn't prevent them from doing so. In fact they use multi-sig output=
s which is worse than OP_RETURN since it's not always prunable, and yet=
let them store much more than 40 bytes.</div><div><br></div><div>For <a hr=
ef=3D"https://github.com/OpenAssets/open-assets-protocol">Open Assets</a>, =
we need to store a URL in the OP_RETURN output (with optionally a hash) plu=
s some bytes of overhead. 40 bytes comes really short for that. The benefit=
of having a URL in there is that any storage mechanism can be used (Web, F=
TP, BitTorrent, MaidSafe...), whereas with only a hash, you have to hardcod=
e the storing mechanism in the protocol (and even then, a hash is not enoug=
h to address a HTTP or FTP resource). Storing only a hash is fine for the m=
ost basic timestamping application, but it's hardly enough to build som=
ething interesting.</div><div><br></div><div>I've counted the number of=
OP_RETURN outputs in the blockchain for the month of October 2014. There w=
ere 1,674 OP_RETURNs for a span of 4,659 blocks.=C2=A0Assuming they were al=
l 40 bytes (the average is probably less than half of that), that means an =
increase of 14.37 bytes per block. Considering a 1 MB block, that's abo=
ut <span id=3D"cwos">0.0013% of the block used up by OP_RETURN data in aver=
age.</span></div><div><span><br></span></div><div><span>Increasing to 80 by=
tes will have a negligible impact on bandwidth and storage requirements, wh=
ile being extremely useful for many use cases where a hash only is not enou=
gh.</span></div><div><span><br></span></div><div><span>Flavien</span></div>=
</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Nov=
17, 2014 at 10:35 AM, Pieter Wuille <span dir=3D"ltr"><<a href=3D"mailt=
o:pieter.wuille@gmail.com" target=3D"_blank">pieter.wuille@gmail.com</a>>=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Mon, Nov 17, 201=
4 at 4:19 AM, Alan Reiner <<a href=3D"mailto:etotheipi@gmail.com">etothe=
ipi@gmail.com</a>> wrote:<br>
><br>
> On 11/16/2014 02:04 PM, Jorge Tim=C3=B3n wrote:<br>
>> I remember people asking in #bitcoin-dev "Does anyone know an=
y use<br>
>> case for greater sizes OP_RETURNs?" and me answering "I =
do not know of<br>
>> any use cases that require bigger sizes".<br>
><br>
> For reference, there was a brief time where I was irritated that the<b=
r>
> size had been reduced to 40 bytes, because I had an application where =
I<br>
> wanted to put ECDSA in signatures in the OP_RETURN, and you're goi=
ng to<br>
> need at least 64 bytes for that.=C2=A0 =C2=A0Unfortunately I can't=
remember now<br>
> what that application was, so it's difficult for me to argue for i=
t.<br>
> But I don't think that's an unreasonable use case:=C2=A0 sendi=
ng a payment<br>
> with a signature, essentially all timestamped in the blockchain.<br>
<br>
</span>You can still send the signature out of band (for example using the<=
br>
payment protocol), and just have the transaction commit to a hash of<br>
that signature (or message in general), either using an OP_RETURN<br>
output to store the hash, or using the pay-to-contract scheme that<br>
Jorge mentioned above. That has exactly the same timestamping<br>
properties.<br>
<br>
My main concern with OP_RETURN is that it seems to encourage people to<br>
use the blockchain as a convenient transport channel, rather than just<br>
for data that the world needs to see to validate it. I'd rather<br>
encourage solutions that don't require additional data there, which in<=
br>
many cases (but not all) is perfectly possible.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Pieter<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
---------------------------------------------------------------------------=
---<br>
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server<br>
from Actuate! Instantly Supercharge Your Business Reports and Dashboards<br=
>
with Interactivity, Sharing, Native Excel Exports, App Integration & mo=
re<br>
Get technology previously reserved for billion-dollar corporations, FREE<br=
>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D157005751&iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D157005751&iu=3D/4140/ostg.clktrk</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br></div>
--001a1134386ead97bc05080c7f4e--
|
