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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <etotheipi@gmail.com>) id 1SXuoz-00064K-VB
for bitcoin-development@lists.sourceforge.net;
Fri, 25 May 2012 13:44:49 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.53 as permitted sender)
client-ip=74.125.82.53; envelope-from=etotheipi@gmail.com;
helo=mail-wg0-f53.google.com;
Received: from mail-wg0-f53.google.com ([74.125.82.53])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SXuor-0003wx-08
for bitcoin-development@lists.sourceforge.net;
Fri, 25 May 2012 13:44:49 +0000
Received: by wgbfm10 with SMTP id fm10so871239wgb.10
for <bitcoin-development@lists.sourceforge.net>;
Fri, 25 May 2012 06:44:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.180.91.196 with SMTP id cg4mr32438468wib.0.1337953474674; Fri,
25 May 2012 06:44:34 -0700 (PDT)
Received: by 10.180.7.102 with HTTP; Fri, 25 May 2012 06:44:34 -0700 (PDT)
Received: by 10.180.7.102 with HTTP; Fri, 25 May 2012 06:44:34 -0700 (PDT)
In-Reply-To: <CALxbBHWe7KhTpdBYKmQ4XUuCdRLefNcdevG+GH7b9_+Sf2VCTw@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>
Date: Fri, 25 May 2012 09:44:34 -0400
Message-ID: <CALf2ePx2u-py5JXSq=uQVmB=GXTYnP5q=8phb3mp=axtwgkfjg@mail.gmail.com>
From: Alan Reiner <etotheipi@gmail.com>
To: Christian Decker <decker.christian@gmail.com>
Content-Type: multipart/alternative; boundary=f46d043bdf769581cc04c0dc9125
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
(etotheipi[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: 1SXuor-0003wx-08
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 13:44:50 -0000
--f46d043bdf769581cc04c0dc9125
Content-Type: text/plain; charset=ISO-8859-1
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
>
>
--f46d043bdf769581cc04c0dc9125
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<p>I like the concept except that it only works if every node connected to =
the miner enforces the rule (if it works).=A0 Once any one of the nodes for=
wards the block,=A0 other nodes see it coming 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"gmail_quote">On May 25, 2012 3:48 AM, "Christian Decker&=
quot; <<a href=3D"mailto:decker.christian@gmail.com">decker.christian@gm=
ail.com</a>> wrote:<br type=3D"attribution"><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">
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">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>
--f46d043bdf769581cc04c0dc9125--
|
