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
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <peter@coinlab.com>) id 1SXvZQ-0007i4-Hn
for bitcoin-development@lists.sourceforge.net;
Fri, 25 May 2012 14:32:48 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of coinlab.com
designates 209.85.213.47 as permitted sender)
client-ip=209.85.213.47; envelope-from=peter@coinlab.com;
helo=mail-yw0-f47.google.com;
Received: from mail-yw0-f47.google.com ([209.85.213.47])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128)
(Exim 4.76) id 1SXvZK-0002RB-MW
for bitcoin-development@lists.sourceforge.net;
Fri, 25 May 2012 14:32:48 +0000
Received: by yhjj56 with SMTP id j56so736917yhj.34
for <bitcoin-development@lists.sourceforge.net>;
Fri, 25 May 2012 07:32:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc:content-type:x-gm-message-state;
bh=AvAXbrwNTJbmPdlbDYoQ/T5iyCFWVivcQWwLlayZ3+0=;
b=VNKnmul57bpT1X57QEeXXQWSJ9GA8H18XVFedDuY3H9MMlDX8HU20fHS37pVt5X0Gd
HFbhbzMKIMgNN/InEHDtzEc64726zAXgfUW0xsbSq5nvzYaIUeRKgivi9Gy1w7GLTePO
yQB/CA8Y46G4ia4hj/zO/ylTdysVEHr+4ae95wxuUHdgZKr/tNAwphBhtKu0zekLlnu6
bZbP6G+4ZIqpT5GZ3PRyDBDX2nCyxj2XM6K6UNdsbv67F5TuebNPKHF/tbBFkub/EJ1f
K88xqSlnKQ9c02XEVM5VaqlvkbHNK3tLmnnB0uFuKmfRN3xs9M1ul57biN5B8RAtyOki
9spQ==
Received: by 10.60.0.193 with SMTP id 1mr3208518oeg.39.1337954482316; Fri, 25
May 2012 07:01:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.41.200 with HTTP; Fri, 25 May 2012 07:00:09 -0700 (PDT)
In-Reply-To: <CALf2ePx2u-py5JXSq=uQVmB=GXTYnP5q=8phb3mp=axtwgkfjg@mail.gmail.com>
References: <CA+8xBpdBe4yR6xkCODL6JQ41Gyx9eWcGGGvcQVt7DCmaEnAhbg@mail.gmail.com>
<201205250045.24540.luke@dashjr.org>
<CA+8xBpfOh-61z_7e1jzz7ZYV4eiCCi=ruQbKBuQp1juuSdYdbQ@mail.gmail.com>
<201205250057.39749.luke@dashjr.org>
<CA+8xBpd1nXWLFihRbnjwftJsCHOK0uVGJjNXOgOETaY5PFGURA@mail.gmail.com>
<CALxbBHWe7KhTpdBYKmQ4XUuCdRLefNcdevG+GH7b9_+Sf2VCTw@mail.gmail.com>
<CALf2ePx2u-py5JXSq=uQVmB=GXTYnP5q=8phb3mp=axtwgkfjg@mail.gmail.com>
From: Peter Vessenes <peter@coinlab.com>
Date: Fri, 25 May 2012 10:00:09 -0400
Message-ID: <CAMGNxUtcpX02ikXX0vzx4rchAnwC2B7qGdGBsCt-bZUjQaaEUA@mail.gmail.com>
To: Alan Reiner <etotheipi@gmail.com>
Content-Type: multipart/alternative; boundary=e89a8fb20116a4e79704c0dccd5b
X-Gm-Message-State: ALoCoQmIC8atDMkBkzcUsdvkt/0TfEVOyUJhn84fPRddtJOKl43cKczfvtlp9kIEc/2CykkPwTSl
X-Spam-Score: -0.5 (/)
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
X-Headers-End: 1SXvZK-0002RB-MW
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Punishing empty 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: Fri, 25 May 2012 14:32:48 -0000
--e89a8fb20116a4e79704c0dccd5b
Content-Type: text/plain; charset=ISO-8859-1
We just implemented our own mining tool, soup-to-nuts, and I would say that
the likely motivation for what I presume are botnet owners is just economic.
It's a lot more work to make sure your merkleing and keeping up-to-date are
happening than it is to just get an 80 byte header from a central server,
and re-calc a single transaction merkle client-side.
Not to mention the extra work to keep track of what version of
getmemorypool output you're receiving work for in a broadly distributed
pool.
For what it's worth, we did this extra engineering work since we care about
Bitcoin, but if I just wanted to pull value out of the ecosystem, we would
have skipped it.
The only solutions to this are economic solutions -- making such 'cheater'
blocks less valuable, or increasing the value of the transactions.
Also note that botnet operators likely care, in the end, about fiat
currency, so going to 25 btc per block in what I think of as transaction
fee subsidies won't necessarily impact this -- it's a matter of what
happens to exchange rates vs generation rates that will matter.
I think we also have to moderate this consideration against the rights (and
arguable benefits) of someone wanting to build an express-delivery mining
service, one that will provide provably faster certification for those
adding a transaction fee of, say, 1 btc.
My own experience now in the MMO world is that we have to carefully
understand how we deal with griefers who control massive resources (compute
or gold-farmers). It may not be a winning battle to choose a solution which
harms the rest of the network in exchange for harming the griefers.
This is definitely out of the box, but one solution might be to change the
difficulty calculations to just ignore 1tx blocks; that would minimize
impact on others to a great extent, and would let someone set up an express
block service if they chose. I guess we'd have to settle on whether or not
such blocks counted towards the issuance countdown as well. Or, we could
allow only 1/10 generation fees on such blocks.
Peter
On Fri, May 25, 2012 at 9:44 AM, Alan Reiner <etotheipi@gmail.com> wrote:
> I like the concept except that it only works if every node connected to
> the miner enforces the rule (if it works). Once any one of the nodes
> forwards the block, other nodes see it coming from a node that can pass
> the challenge.
>
> I don't think any solution based on node queries will succeed, especially
> if it requires spontaneous super-majority-of-nodes acceptance. I think
> it's gotta be based on the block itself and each nodes' own info.
>
> If you could spontaneously get all miners to agree not to build off of
> anti-social blocks (however that is defined) , it would have a chance of
> making a difference, but individual miners would have an advantage
> building off the antisocial block because they only need to produce one to
> create the longest chain (and collect reward) while the miners following
> the rules need two blocks.
>
> --Sent from my overpriced smartphone
> On May 25, 2012 3:48 AM, "Christian Decker" <decker.christian@gmail.com>
> wrote:
>
>> How about a simple proof of work test? This one though does not ask for
>> CPU work but asks the miner for a random old transaction. If the miner
>> really stores the entire blockchain he will not have any problem answering
>> to that getdata request, whereas a botnet would have to ask someone else
>> for it, which could be detected if the response time deviates too much from
>> what has been previously measured (compare it against getdata for the block
>> they advertise). It's not perfect but it allows an estimate of whether it
>> is a chainless miner.
>>
>> Regards,
>> Chris
>> --
>> Christian Decker
>>
>>
>>
>> On Fri, May 25, 2012 at 3:17 AM, Jeff Garzik <jgarzik@exmulti.com> wrote:
>>
>>> On Thu, May 24, 2012 at 8:57 PM, Luke-Jr <luke@dashjr.org> wrote:
>>> > Block times are not accurate enough for that.
>>>
>>> The times in your log are very accurate, assuming your system clock is
>>> remotely accurate.
>>>
>>> --
>>> Jeff Garzik
>>> exMULTI, Inc.
>>> jgarzik@exmulti.com
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Peter J. Vessenes
CEO, CoinLab
M: 206.595.9839
Skype: vessenes
Google+ <https://plus.google.com/112885659993091300749>
--e89a8fb20116a4e79704c0dccd5b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
We just implemented our own mining tool, soup-to-nuts, and I would say that=
the likely motivation for what I presume are botnet owners is just economi=
c.<div><br></div><div>It's a lot more work to make sure your merkleing =
and keeping up-to-date are happening than it is to just get an 80 byte head=
er from a central server, and re-calc a single transaction merkle client-si=
de.</div>
<div><br></div><div>Not to mention the extra work to keep track of what ver=
sion of getmemorypool output you're receiving work for in a broadly dis=
tributed pool.=A0</div><div><br></div><div>For what it's worth, we did =
this extra engineering work since we care about Bitcoin, but if I just want=
ed to pull value out of the ecosystem, we would have skipped it.=A0</div>
<div><br></div><div>The only solutions to this are economic solutions -- ma=
king such 'cheater' blocks less valuable, or increasing the value o=
f the transactions.</div><div><br></div><div>Also note that botnet operator=
s likely care, in the end, about fiat currency, so going to 25 btc per bloc=
k in what I think of as transaction fee subsidies won't necessarily imp=
act this -- it's a matter of what happens to exchange rates vs generati=
on rates that will matter.</div>
<div><br></div><div>I think we also have to moderate this consideration aga=
inst the rights (and arguable benefits) of someone wanting to build an expr=
ess-delivery mining service, one that will provide provably faster certific=
ation for those adding a transaction fee of, say, 1 btc.=A0</div>
<div><br></div><div>My own experience now in the MMO world is that we have =
to carefully understand how we deal with griefers who control massive resou=
rces (compute or gold-farmers). It may not be a winning battle to choose a =
solution which harms the rest of the network in exchange for harming the gr=
iefers.</div>
<div><br></div><div>This is definitely out of the box, but one solution mig=
ht be to change the difficulty calculations to just ignore 1tx blocks; that=
would minimize impact on others to a great extent, and would let someone s=
et up an express block service if they chose. I guess we'd have to sett=
le on whether or not such blocks counted towards the issuance countdown as =
well. Or, we could allow only 1/10 generation fees on such blocks.</div>
<div><br></div><div>Peter</div><div><br></div><div><br><div class=3D"gmail_=
quote">On Fri, May 25, 2012 at 9:44 AM, Alan Reiner <span dir=3D"ltr"><<=
a href=3D"mailto:etotheipi@gmail.com" target=3D"_blank">etotheipi@gmail.com=
</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><p>I like the concept except that it only wo=
rks if every node connected to the miner enforces the rule (if it works).=
=A0 Once any one of the nodes forwards the block,=A0 other nodes see it com=
ing from a node that can pass the challenge. </p>
<p>I don't think any solution based on node queries will succeed,=A0 es=
pecially if it requires spontaneous super-majority-of-nodes acceptance.=A0 =
I think it's gotta be based on the block itself and each nodes' own=
info. </p>
<p>If you could spontaneously get all miners to agree not to build off of a=
nti-social blocks (however that is defined) ,=A0 it would have a chance of =
making a difference,=A0 but individual miners would have an advantage build=
ing off the antisocial block because they only need to produce one to creat=
e the longest chain (and collect reward) while the miners following the rul=
es need two blocks. </p>
<p>--Sent from my overpriced smartphone </p><div class=3D"HOEnZb"><div clas=
s=3D"h5">
<div class=3D"gmail_quote">On May 25, 2012 3:48 AM, "Christian Decker&=
quot; <<a href=3D"mailto:decker.christian@gmail.com" target=3D"_blank">d=
ecker.christian@gmail.com</a>> wrote:<br type=3D"attribution"><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">
How about a simple proof of work test? This one though does not ask for CPU=
work but asks the miner for a random old transaction. If the miner really =
stores the entire blockchain he will not have any problem answering to that=
getdata request, whereas a botnet would have to ask someone else for it, w=
hich could be detected if the response time deviates too much from what has=
been previously measured (compare it against getdata for the block they ad=
vertise). It's not perfect but it allows an estimate of whether it is a=
chainless miner.<div>
<br></div><div>Regards,</div><div>Chris</div><div>--<br>Christian Decker<br=
><br>
<br><br><div class=3D"gmail_quote">On Fri, May 25, 2012 at 3:17 AM, Jeff Ga=
rzik <span dir=3D"ltr"><<a href=3D"mailto:jgarzik@exmulti.com" target=3D=
"_blank">jgarzik@exmulti.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">
<div>On Thu, May 24, 2012 at 8:57 PM, Luke-Jr <<a href=3D"mailto:luke@da=
shjr.org" target=3D"_blank">luke@dashjr.org</a>> wrote:<br>
> Block times are not accurate enough for that.<br>
<br>
</div>The times in your log are very accurate, assuming your system clock i=
s<br>
remotely accurate.<br>
<div><br>
--<br>
Jeff Garzik<br>
exMULTI, Inc.<br>
<a href=3D"mailto:jgarzik@exmulti.com" target=3D"_blank">jgarzik@exmulti.co=
m</a><br>
<br>
</div><div><div>-----------------------------------------------------------=
-------------------<br>
Live Security Virtual Conference<br>
Exclusive live event will cover all the ways today's security and<br>
threat landscape has changed and how IT managers can respond. Discussions<b=
r>
will include endpoint security, mobile security and the latest in malware<b=
r>
threats. <a href=3D"http://www.accelacomm.com/jaw/sfrnl04242012/114/5012226=
3/" target=3D"_blank">http://www.accelacomm.com/jaw/sfrnl04242012/114/50122=
263/</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@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>
<br>-----------------------------------------------------------------------=
-------<br>
Live Security Virtual Conference<br>
Exclusive live event will cover all the ways today's security and<br>
threat landscape has changed and how IT managers can respond. Discussions<b=
r>
will include endpoint security, mobile security and the latest in malware<b=
r>
threats. <a href=3D"http://www.accelacomm.com/jaw/sfrnl04242012/114/5012226=
3/" target=3D"_blank">http://www.accelacomm.com/jaw/sfrnl04242012/114/50122=
263/</a><br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@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>
<br></blockquote></div>
</div></div><br>-----------------------------------------------------------=
-------------------<br>
Live Security Virtual Conference<br>
Exclusive live event will cover all the ways today's security and<br>
threat landscape has changed and how IT managers can respond. Discussions<b=
r>
will include endpoint security, mobile security and the latest in malware<b=
r>
threats. <a href=3D"http://www.accelacomm.com/jaw/sfrnl04242012/114/5012226=
3/" target=3D"_blank">http://www.accelacomm.com/jaw/sfrnl04242012/114/50122=
263/</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>
<br></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><table s=
tyle=3D"font-family:Times"><tbody><tr><td><img src=3D"http://coinlab.com/im=
ages/coinlab-logo.png"></td><td valign=3D"bottom"><div style=3D"font-family=
:RobotoLight,'Lucida Grande',Helmet,Freesans,sans-serif;font-size:1=
6px;line-height:20px">
Peter J. Vessenes<br>CEO, CoinLab<br>M: 206.595.9839<br>Skype: vessenes<br>=
<a href=3D"https://plus.google.com/112885659993091300749" target=3D"_blank"=
>Google+</a></div></td></tr></tbody></table><br>
</div>
--e89a8fb20116a4e79704c0dccd5b--
|