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
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <melvincarvalho@gmail.com>) id 1UkiNv-0007n6-Vt
for bitcoin-development@lists.sourceforge.net;
Thu, 06 Jun 2013 22:10:20 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.48 as permitted sender)
client-ip=209.85.215.48; envelope-from=melvincarvalho@gmail.com;
helo=mail-la0-f48.google.com;
Received: from mail-la0-f48.google.com ([209.85.215.48])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UkiNu-0002FQ-CH
for bitcoin-development@lists.sourceforge.net;
Thu, 06 Jun 2013 22:10:19 +0000
Received: by mail-la0-f48.google.com with SMTP id lx15so2059126lab.7
for <bitcoin-development@lists.sourceforge.net>;
Thu, 06 Jun 2013 15:10:11 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.219.133 with SMTP id po5mr792111lbc.80.1370556611587;
Thu, 06 Jun 2013 15:10:11 -0700 (PDT)
Received: by 10.112.2.8 with HTTP; Thu, 6 Jun 2013 15:10:11 -0700 (PDT)
In-Reply-To: <201306062148.16611.luke@dashjr.org>
References: <201306061914.20006.luke@dashjr.org>
<201306062007.41398.luke@dashjr.org>
<CAFmyj8zDCjGR6cLUXQnWP4G0k6A85vdNW03k5NPAVyoJj0eEnQ@mail.gmail.com>
<201306062148.16611.luke@dashjr.org>
Date: Fri, 7 Jun 2013 00:10:11 +0200
Message-ID: <CAKaEYhKVmhrvYLVR7s-WkT+kC-DWm=faXj6fJ0rp1yhytoQ15Q@mail.gmail.com>
From: Melvin Carvalho <melvincarvalho@gmail.com>
To: Luke-Jr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=001a11c32ed8fa75f404de8393d0
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(melvincarvalho[at]gmail.com)
-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: 1UkiNu-0002FQ-CH
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal: soft-fork to make
anyone-can-spend outputs unspendable for 100 blocks
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: Thu, 06 Jun 2013 22:10:20 -0000
--001a11c32ed8fa75f404de8393d0
Content-Type: text/plain; charset=ISO-8859-1
On 6 June 2013 23:48, Luke-Jr <luke@dashjr.org> wrote:
> On Thursday, June 06, 2013 8:16:40 PM Andreas M. Antonopoulos wrote:
> > > This doesn't work like you might think: first of all, the fees today
> are
> > > greatly subsidized - the actual cost to store data in the blockchain is
> > > much higher than most storage solutions. Secondly, only the miner
> receives
> > > the fees, not the majority of nodes which have to bear the burden of
> the
> > > data. That is, the fee system is setup as an antispam/deterrant, not as
> > > payment for
> > > storage.
> >
> > There's a difference between storing the content itself, and storing
> just a
> > hash to content (which however is not spendable payment). I undertand why
> > content itself doesn't belong. But it goes too far to say that only
> > payments should be allowed.
>
> Because payments are the only thing everyone using Bitcoin has agreed to
> use
> the blockchain for. Furthermore, there is no *reason* to store
> non-payments in
> the blockchain. If there was in fact such a use case, things might be
> arguable
> - but there isn't any I'm aware of.
>
Two quotes satoshi:
"Piling every proof-of-work quorum system in the world into one dataset
doesn't scale."
and
"I like Hal Finney's idea for user-friendly timestamping. Convert the hash
of a file to a bitcoin address and send 0.01 to it"
This leads me to believe, that while bitcoin should not be over used as a
time stamp server, there could be a balance reached for casual time stamp
recording as part of satoshi's concept.
What we call "spam" is to a degree subjective, and I think not always
obvious, tho in some cases it clearly is.
> > If the fees are not enough, fix the fee structure, don't stop incredibly
> > innovative and promising uses of the distributed timestamping database.
> > That is definitely throwing the baby out with the bathwater. If the issue
> > is size, then address that, rather than the content itself.
>
> The issue is using other peoples' resources for something they did not
> agree
> to use it for. The fees aren't merely "not enough", they were never
> *intended*
> to be "cost of storage". They are "cost of security" and "prevent
> spamming".
>
> > Discriminating based on transaction content violates neutrality of the
> > protocol and in my mind removes a very very large possibility of future
> > innovation. If bitcoin is a *platform* and not just a payment system,
> then
> > it needs to be neutral to content, like TCP/IP so that other protocols
> can
> > be layered. Solve the size problem itself, without picking and chosing
> > which uses of bitcoin are good and which are "bad" or "spam". I think it
> > risks killing a tremendous amount of innovation just as it is starting.
>
> The concepts behind Bitcoin are applicable to future innovation, but this
> can
> all be accomplished without spamming Bitcoin itself.
>
> > > Not the same thing at all; nobody is forced to store/relay
> > > video/voice/images without reimbursement. On the other hand, any full
> > > Bitcoin node is required to at least download the entire blockchain
> once.
> > > And the network as a whole suffers if nodes decide to start not-storing
> > > parts of the blockchain they don't want to deal with.
> > >
> > > So don't store content, but allow hashes of content.
> >
> > Again, I think it is extreme and extremely restrictive to say that ONLY
> > payments are allowed.
>
> Non-payments are quite possible without the Bitcoin blockchain itself. If
> you're worried that not enough people will store the
> alternative-non-payment
> data, then you are essentially saying that voluntary participation is not
> enough and that forced storage is your solution. I don't think this is what
> you intend...
>
> > > This is how merged mining solves the problem. A single extra hash in
> the
> > > coinbase can link the bitcoin blockchain up with unlimited other data.
> >
> > Can you explain this part or refer me to some docs? What do you mean by
> > "coinbase", I assume not the company.
>
> The Bitcoin blockchain protocol has 95 bytes per block reserved for miners
> to
> put extra data. Currently, this is used for extranonces, political or other
> short messages (such as in the Genesis block), miner "signatures", and
> also,
> as I mentioned, merged mining. Merged mining works by tying a non-
> transactional merkle tree to the blockchain. The block coinbase stores the
> hash of the top of this merkle tree, so any data within the merkle tree can
> prove it is associated to the block. The merged mining merkle tree then
> stores
> hashes of multiple other data sets: for example, a Namecoin block can be
> referenced in a merged mining merkle tree, to use the Bitcoin block's
> proof-
> of-work for itself (so, miners can mine both Bitcoin and Namecoin using the
> same hashing effort). You could also add other non-transactional blocks to
> the
> merged mining merkle tree, for generic timestamping or really anything at
> all.
>
> Luke
>
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> http://p.sf.net/sfu/servicenow-d2d-j
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--001a11c32ed8fa75f404de8393d0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 6 June 2013 23:48, Luke-Jr <span dir=3D"ltr"><<a href=3D"mail=
to:luke@dashjr.org" target=3D"_blank">luke@dashjr.org</a>></span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=3D"im">On Thursday, June 06, 2013 8:16:40 PM Andreas M. Antonopo=
ulos wrote:<br>
> > This doesn't work like you might think: first of all, the fee=
s today are<br>
> > greatly subsidized - the actual cost to store data in the blockch=
ain is<br>
> > much higher than most storage solutions. Secondly, only the miner=
receives<br>
> > the fees, not the majority of nodes which have to bear the burden=
of the<br>
> > data. That is, the fee system is setup as an antispam/deterrant, =
not as<br>
> > payment for<br>
> > storage.<br>
><br>
> There's a difference between storing the content itself, and stori=
ng just a<br>
> hash to content (which however is not spendable payment). I undertand =
why<br>
> content itself doesn't belong. But it goes too far to say that onl=
y<br>
> payments should be allowed.<br>
<br>
</div>Because payments are the only thing everyone using Bitcoin has agreed=
to use<br>
the blockchain for. Furthermore, there is no *reason* to store non-payments=
in<br>
the blockchain. If there was in fact such a use case, things might be argua=
ble<br>
- but there isn't any I'm aware of.<br></blockquote><div><br></div>=
<div>Two quotes satoshi:<br><br>"Piling every proof-of-work quorum sys=
tem in the world into one dataset doesn't scale."<br><br></div>
<div>and<br></div><div><br>"I like Hal Finney's idea for user-frie=
ndly timestamping.=A0 Convert the hash of a file to a bitcoin address and s=
end 0.01 to it"<br><br></div><div>This leads me to believe, that while=
bitcoin should not be over used as a time stamp server, there could be a b=
alance reached for casual time stamp recording as part of satoshi's con=
cept.<br>
<br></div><div>What we call "spam" is to a degree subjective, and=
I think not always obvious, tho in some cases it clearly is.<br></div><div=
><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=3D"im"><br>
> If the fees are not enough, fix the fee structure, don't stop incr=
edibly<br>
> innovative and promising uses of the distributed timestamping database=
.<br>
> That is definitely throwing the baby out with the bathwater. If the is=
sue<br>
> is size, then address that, rather than the content itself.<br>
<br>
</div>The issue is using other peoples' resources for something they di=
d not agree<br>
to use it for. The fees aren't merely "not enough", they were=
never *intended*<br>
to be "cost of storage". They are "cost of security" an=
d "prevent spamming".<br>
<div class=3D"im"><br>
> Discriminating based on transaction content violates neutrality of the=
<br>
> protocol and in my mind removes a very very large possibility of futur=
e<br>
</div>> innovation. If bitcoin is a *platform* and not just a payment sy=
stem, then<br>
<div class=3D"im">> it needs to be neutral to content, like TCP/IP so th=
at other protocols can<br>
> be layered. Solve the size problem itself, without picking and chosing=
<br>
> which uses of bitcoin are good and which are "bad" or "=
spam". I think it<br>
> risks killing a tremendous amount of innovation just as it is starting=
.<br>
<br>
</div>The concepts behind Bitcoin are applicable to future innovation, but =
this can<br>
all be accomplished without spamming Bitcoin itself.<br>
<div class=3D"im"><br>
> > Not the same thing at all; nobody is forced to store/relay<br>
> > video/voice/images without reimbursement. On the other hand, any =
full<br>
> > Bitcoin node is required to at least download the entire blockcha=
in once.<br>
> > And the network as a whole suffers if nodes decide to start not-s=
toring<br>
> > parts of the blockchain they don't want to deal with.<br>
> ><br>
> > So don't store content, but allow hashes of content.<br>
><br>
> Again, I think it is extreme and extremely restrictive to say that ONL=
Y<br>
> payments are allowed.<br>
<br>
</div>Non-payments are quite possible without the Bitcoin blockchain itself=
. If<br>
you're worried that not enough people will store the alternative-non-pa=
yment<br>
data, then you are essentially saying that voluntary participation is not<b=
r>
enough and that forced storage is your solution. I don't think this is =
what<br>
you intend...<br>
<div class=3D"im"><br>
> > This is how merged mining solves the problem. A single extra hash=
in the<br>
> > coinbase can link the bitcoin blockchain up with unlimited other =
data.<br>
><br>
> Can you explain this part or refer me to some docs? What do you mean b=
y<br>
> "coinbase", I assume not the company.<br>
<br>
</div>The Bitcoin blockchain protocol has 95 bytes per block reserved for m=
iners to<br>
put extra data. Currently, this is used for extranonces, political or other=
<br>
short messages (such as in the Genesis block), miner "signatures"=
, and also,<br>
as I mentioned, merged mining. Merged mining works by tying a non-<br>
transactional merkle tree to the blockchain. The block coinbase stores the<=
br>
hash of the top of this merkle tree, so any data within the merkle tree can=
<br>
prove it is associated to the block. The merged mining merkle tree then sto=
res<br>
hashes of multiple other data sets: for example, a Namecoin block can be<br=
>
referenced in a merged mining merkle tree, to use the Bitcoin block's p=
roof-<br>
of-work for itself (so, miners can mine both Bitcoin and Namecoin using the=
<br>
same hashing effort). You could also add other non-transactional blocks to =
the<br>
merged mining merkle tree, for generic timestamping or really anything at a=
ll.<br>
<span class=3D""><font color=3D"#888888"><br>
Luke<br>
</font></span><div class=3D""><div class=3D"h5"><br>
---------------------------------------------------------------------------=
---<br>
How ServiceNow helps IT people transform IT departments:<br>
1. A cloud service to automate IT design, transition and operations<br>
2. Dashboards that offer high-level views of enterprise services<br>
3. A single system of record for all IT processes<br>
<a href=3D"http://p.sf.net/sfu/servicenow-d2d-j" target=3D"_blank">http://p=
.sf.net/sfu/servicenow-d2d-j</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></div>
--001a11c32ed8fa75f404de8393d0--
|