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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <wtogami@gmail.com>) id 1VAU4D-00040q-GZ
for bitcoin-development@lists.sourceforge.net;
Sat, 17 Aug 2013 00:08:29 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.48 as permitted sender)
client-ip=209.85.220.48; envelope-from=wtogami@gmail.com;
helo=mail-pa0-f48.google.com;
Received: from mail-pa0-f48.google.com ([209.85.220.48])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VAU4C-0004ql-6n
for bitcoin-development@lists.sourceforge.net;
Sat, 17 Aug 2013 00:08:29 +0000
Received: by mail-pa0-f48.google.com with SMTP id kp13so2418169pab.7
for <bitcoin-development@lists.sourceforge.net>;
Fri, 16 Aug 2013 17:08:22 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.69.8.65 with SMTP id di1mr246720pbd.32.1376698102255; Fri,
16 Aug 2013 17:08:22 -0700 (PDT)
Received: by 10.66.72.225 with HTTP; Fri, 16 Aug 2013 17:08:22 -0700 (PDT)
In-Reply-To: <CANEZrP3hHh3k5+ePGbqVeyo3oV=RTy36FA+8MbOZXg3yMqRxAw@mail.gmail.com>
References: <CABsx9T32q8mKgtmsaZgh7nuhHY5cExeW=FiadzXq3jXVP=NBTw@mail.gmail.com>
<CANEZrP0PEcP339MKRyrHXHCCsP3BxRHT-ZfKRQ7G2Ou+15CD7A@mail.gmail.com>
<CANEZrP3LAR0erjgmTHruLwPNDdx-OVyb9KK52E6UnmE4ZuBrvQ@mail.gmail.com>
<20130816140116.GB16201@petertodd.org>
<20130816141536.GD16201@petertodd.org>
<CAEz79PoK9u9ffJ5jR8yXk8eCFP0Ytk_bno0mpcpM24mt-GGg5w@mail.gmail.com>
<CANEZrP3hHh3k5+ePGbqVeyo3oV=RTy36FA+8MbOZXg3yMqRxAw@mail.gmail.com>
Date: Fri, 16 Aug 2013 14:08:22 -1000
Message-ID: <CAEz79Pq87Bp-SZsadHaRPk9HuzoeYrCK7noHm+-0iqNP0DFKuA@mail.gmail.com>
From: "Warren Togami Jr." <wtogami@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=047d7b5d48dc59157504e4198162
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
(wtogami[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: 1VAU4C-0004ql-6n
Subject: Re: [Bitcoin-development] Gavin's post-0.9 TODO list...
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: Sat, 17 Aug 2013 00:08:29 -0000
--047d7b5d48dc59157504e4198162
Content-Type: text/plain; charset=UTF-8
A sane default that better protects users could be...
If (plugged into power) && (wifi) then non-bloom peers are OK. It would
protect those users more than reliance upon on the smaller subset of bloom
nodes. Scale back to the less secure behavior when battery and bandwidth
matters.
Warren
On Fri, Aug 16, 2013 at 4:36 AM, Mike Hearn <mike@plan99.net> wrote:
> That change was made in response to user complaints. Heck we get
> complaints about battery life and bandwidth impact even with Bloom
> filtering. We can't just randomly start using peoples bandwidth for
> relaying blocks, especially as I guess most SPV nodes are behind NAT.
>
> If Gavin is right and the future is dominated by mobiles and tablets, then
> it will require a change of thinking in how P2P networks work. I think
> there are plenty of people with private servers who would be willing to run
> nodes though. I'm not too worried about this.
>
>
> On Fri, Aug 16, 2013 at 4:27 PM, Warren Togami Jr. <wtogami@gmail.com>wrote:
>
>> bitcoinj-0.10 release notes:
>>
>> - We now require Bloom-capable (0.8+) peers by default and will
>> disconnect from older nodes. This avoids accidental bandwidth saturation on
>> mobile devices.
>>
>> Given the user-security concern that Peter brings up, reconsideration of
>> this new default behavior in SPV clients may be warranted.
>>
>>
>>
>> On Fri, Aug 16, 2013 at 4:15 AM, Peter Todd <pete@petertodd.org> wrote:
>>
>>> On Fri, Aug 16, 2013 at 10:01:16AM -0400, Peter Todd wrote:
>>> > Doing this also makes it more difficult to sybil the network - for
>>> > instance right now you can create "SPV honeypots" that allow incoming
>>> > connections only from SPV nodes, thus attracting a disproportionate %
>>> of
>>> > the total SPV population given a relatively small number of nodes. You
>>> > can then use that to harm SPV nodes by, for instance, making a % of
>>> > transactions be dropped deterministicly, either by the bloom matching
>>> > code, or when sent. Users unlucky enough to be surrounded by sybil
>>> nodes
>>> > will have their transactions mysteriously fail to arrive in their
>>> > wallets, or have their transactions mysteriously never confirm. Given
>>> > how few full nodes there are, it probably won't take very many
>>> honeypots
>>> > to pull off this attack, especially if you combine it with a
>>> > simultaneous max connections or bloom io attack to degrade the capacity
>>> > of honest nodes.
>>>
>>> Oh, here's an even better way to do the "tx drop" attack: when you drop
>>> a transaction, make a fake one that pays the same scriptPubKeys with the
>>> same amount, and send it to the SPV peer instead. They'll see the
>>> transaction go through and show up in their wallet, but it'll look like
>>> it got stuck and never confirmed. They'll soon wind up with a wallet
>>> full of useless transactions, effectively locking them out of their
>>> money.
>>>
>>> Here's another question for you Mike: So does bitcoinj have any
>>> protections against peers flooding you with useless garbage? It'd be
>>> easy to rack up a user's data bill for instance by just creating junk
>>> unconfirmed transactions matching the bloom filter.
>>>
>>> --
>>> 'peter'[:-1]@petertodd.org
>>> 0000000000000018dcf5bcc3f018a05517ba1c479b432ba422015d4506496e55
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>>> It's a free troubleshooting tool designed for production.
>>> Get down to code-level detail for bottlenecks, with <2% overhead.
>>> Download for free and get started troubleshooting in minutes.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>> It's a free troubleshooting tool designed for production.
>> Get down to code-level detail for bottlenecks, with <2% overhead.
>> Download for free and get started troubleshooting in minutes.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
--047d7b5d48dc59157504e4198162
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>A sane default that better protects users could be...=
</div><div><br></div><div>If (plugged into power) && (wifi) then no=
n-bloom peers are OK. =C2=A0It would protect those users more than reliance=
upon on the smaller subset of bloom nodes. =C2=A0Scale back to the less se=
cure behavior when battery and bandwidth matters.<br>
</div><div><br></div><div>Warren</div></div><div class=3D"gmail_extra"><br>=
<br><div class=3D"gmail_quote">On Fri, Aug 16, 2013 at 4:36 AM, Mike Hearn =
<span dir=3D"ltr"><<a href=3D"mailto:mike@plan99.net" target=3D"_blank">=
mike@plan99.net</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"><div dir=3D"ltr">That change was made in res=
ponse to user complaints. Heck we get complaints about battery life and ban=
dwidth impact even with Bloom filtering. We can't just randomly start u=
sing peoples bandwidth for relaying blocks, especially as I guess most SPV =
nodes are behind NAT.<div>
<br></div><div>If Gavin is right and the future is dominated by mobiles and=
tablets, then it will require a change of thinking in how P2P networks wor=
k. I think there are plenty of people with private servers who would be wil=
ling to run nodes though. I'm not too worried about this.</div>
</div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra"><b=
r><br><div class=3D"gmail_quote">On Fri, Aug 16, 2013 at 4:27 PM, Warren To=
gami Jr. <span dir=3D"ltr"><<a href=3D"mailto:wtogami@gmail.com" target=
=3D"_blank">wtogami@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"><div dir=3D"ltr">bitcoinj-0.10 release notes=
:<div><ul style=3D"font-family:arial,sans-serif;font-size:12.80000019073486=
3px;padding-left:25px;max-width:62em">
<li style=3D"margin-left:15px;margin-bottom:0.3em">We now require Bloom-cap=
able (0.8+) peers by default and will disconnect from older nodes. This avo=
ids accidental bandwidth saturation on mobile devices.</li>
</ul><div><font face=3D"arial, sans-serif">Given the user-security concern =
that Peter brings up, reconsideration of this new default behavior in SPV c=
lients may be warranted.</font></div><div><br></div></div></div><div class=
=3D"gmail_extra">
<br><br><div class=3D"gmail_quote"><div><div>On Fri, Aug 16, 2013 at 4:15 A=
M, Peter Todd <span dir=3D"ltr"><<a href=3D"mailto:pete@petertodd.org" t=
arget=3D"_blank">pete@petertodd.org</a>></span> wrote:<br></div>
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div><div>
<div>On Fri, Aug 16, 2013 at 10:01:16AM -0400, Peter Todd wrote:<br>
> Doing this also makes it more difficult to sybil the network - for<br>
> instance right now you can create "SPV honeypots" that allow=
incoming<br>
> connections only from SPV nodes, thus attracting a disproportionate % =
of<br>
> the total SPV population given a relatively small number of nodes. You=
<br>
> can then use that to harm SPV nodes by, for instance, making a % of<br=
>
> transactions be dropped deterministicly, either by the bloom matching<=
br>
> code, or when sent. Users unlucky enough to be surrounded by sybil nod=
es<br>
> will have their transactions mysteriously fail to arrive in their<br>
> wallets, or have their transactions mysteriously never confirm. Given<=
br>
> how few full nodes there are, it probably won't take very many hon=
eypots<br>
> to pull off this attack, especially if you combine it with a<br>
> simultaneous max connections or bloom io attack to degrade the capacit=
y<br>
> of honest nodes.<br>
<br>
</div>Oh, here's an even better way to do the "tx drop" attac=
k: when you drop<br>
a transaction, make a fake one that pays the same scriptPubKeys with the<br=
>
same amount, and send it to the SPV peer instead. They'll see the<br>
transaction go through and show up in their wallet, but it'll look like=
<br>
it got stuck and never confirmed. They'll soon wind up with a wallet<br=
>
full of useless transactions, effectively locking them out of their<br>
money.<br>
<br>
Here's another question for you Mike: So does bitcoinj have any<br>
protections against peers flooding you with useless garbage? It'd be<br=
>
easy to rack up a user's data bill for instance by just creating junk<b=
r>
unconfirmed transactions matching the bloom filter.<br>
<div><div><br>
--<br>
'peter'[:-1]@<a href=3D"http://petertodd.org" target=3D"_blank">pet=
ertodd.org</a><br>
0000000000000018dcf5bcc3f018a05517ba1c479b432ba422015d4506496e55<br>
</div></div><br></div></div><div>------------------------------------------=
------------------------------------<br>
Get 100% visibility into Java/.NET code with AppDynamics Lite!<br>
It's a free troubleshooting tool designed for production.<br>
Get down to code-level detail for bottlenecks, with <2% overhead.<br>
Download for free and get started troubleshooting in minutes.<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D48897031&iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D48897031&iu=3D/4140/ostg.clktrk</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></div></blockquote></div><br></div>
<br>-----------------------------------------------------------------------=
-------<br>
Get 100% visibility into Java/.NET code with AppDynamics Lite!<br>
It's a free troubleshooting tool designed for production.<br>
Get down to code-level detail for bottlenecks, with <2% overhead.<br>
Download for free and get started troubleshooting in minutes.<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D48897031&iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D48897031&iu=3D/4140/ostg.clktrk</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><br></div>
</div></div></blockquote></div><br></div>
--047d7b5d48dc59157504e4198162--
|
