summaryrefslogtreecommitdiff
path: root/c7/b13b18b187790ef5fa114085e8be09829a2b29
blob: 96fa52cc01aaf1881d6ca047178c9fbd64b99204 (plain)
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
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1VAKM7-000484-OX
	for bitcoin-development@lists.sourceforge.net;
	Fri, 16 Aug 2013 13:46:19 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.170 as permitted sender)
	client-ip=209.85.214.170; envelope-from=mh.in.england@gmail.com;
	helo=mail-ob0-f170.google.com; 
Received: from mail-ob0-f170.google.com ([209.85.214.170])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1VAKM6-0002M9-DR
	for bitcoin-development@lists.sourceforge.net;
	Fri, 16 Aug 2013 13:46:19 +0000
Received: by mail-ob0-f170.google.com with SMTP id eh20so2102343obb.1
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 16 Aug 2013 06:46:13 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.250.232 with SMTP id zf8mr11655obc.75.1376660772881;
	Fri, 16 Aug 2013 06:46:12 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.80.165 with HTTP; Fri, 16 Aug 2013 06:46:12 -0700 (PDT)
In-Reply-To: <CAEz79PqpQ0NG3WHHo7gqoZJVWqAQ4GwUaqSD_7LzWSvSQCHHig@mail.gmail.com>
References: <CABsx9T32q8mKgtmsaZgh7nuhHY5cExeW=FiadzXq3jXVP=NBTw@mail.gmail.com>
	<CANEZrP0PEcP339MKRyrHXHCCsP3BxRHT-ZfKRQ7G2Ou+15CD7A@mail.gmail.com>
	<CANEZrP3LAR0erjgmTHruLwPNDdx-OVyb9KK52E6UnmE4ZuBrvQ@mail.gmail.com>
	<CAEz79PqpQ0NG3WHHo7gqoZJVWqAQ4GwUaqSD_7LzWSvSQCHHig@mail.gmail.com>
Date: Fri, 16 Aug 2013 15:46:12 +0200
X-Google-Sender-Auth: RDPlZ_a8ldSCHPqGUIBtFgf3OUk
Message-ID: <CANEZrP2cdQ4vyO5N42FO=Y6c_bt6yTes9p5UTs+cD66YiNC08Q@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: "Warren Togami Jr." <wtogami@gmail.com>
Content-Type: multipart/alternative; boundary=089e0160c454580dc804e410d003
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(mh.in.england[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	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: 1VAKM6-0002M9-DR
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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: Fri, 16 Aug 2013 13:46:19 -0000

--089e0160c454580dc804e410d003
Content-Type: text/plain; charset=UTF-8

A ban-subnet RPC would be a reasonable addition, but obviously DoS
attackers that are IP or bandwidth constrained are really just script
kiddies. Also anything that involves every node operator doing manual
intervention rather works against decentralisation and having a big
network. That's why I keep pushing for automated heuristic driven
prioritisation.


On Fri, Aug 16, 2013 at 3:41 PM, Warren Togami Jr. <wtogami@gmail.com>wrote:

>
> https://togami.com/~warren/archive/2013/example-bitcoind-dos-mitigation-via-iptables.txt
> *Anti-DoS Low Hanging Fruit: source IP or subnet connection limits*
> If you disallow the same IP and/or subnet from establishing too many TCP
> connections with your node, it becomes more expensive for attackers to use
> a single host exhaust a target node's resources.  This iptables firewall
> based example has almost zero drawbacks, but it is too complicated for most
> people to deploy.  Yes, there is a small chance that you will block
> legitimate connections, but there are plenty of other nodes for random
> connections to choose from.  Configurable per source IP and source subnet
> limits with sane defaults enforced by bitcoind itself would be a big
> improvement over the current situation where one host address can consume
> limited resources of many target nodes.
>
> This doesn't remove the risk of a network-wide connection exhaustion
> attack by a determined attacker, but it at least makes multiple types of
> attacks a lot more expensive.  This also doesn't do much against the io
> vulnerability, which would require major redesigns to prevent in Bitcoin.
>
>
> https://github.com/litecoin-project/litecoin/commit/db4d8e21d99551bef4c807aa1534a074e4b7964d
> *Want to safely delay the block size limit increase for another year or
> two?*  This patch alone enables that.
>
>
>
> On Fri, Aug 16, 2013 at 2:24 AM, Mike Hearn <mike@plan99.net> wrote:
>
>> The only other thing I'd like to see there is the start of a new anti-DoS
>> framework. I think once the outline is in place other people will be able
>> to fill it in appropriately. But the current framework has to be left
>> behind.
>>
>> If I had to choose one thing to evict to make time for that, it'd be the
>> whitepapers. At the moment we still have plenty of headroom in block sizes,
>> even post April. It can probably be safely delayed for a while.
>>
>>
>> On Fri, Aug 16, 2013 at 2:11 PM, Mike Hearn <mike@plan99.net> wrote:
>>
>>> Cool. Maybe it's time for another development update on the foundation
>>> blog?
>>>
>>>
>>> On Fri, Aug 16, 2013 at 3:00 AM, Gavin Andresen <gavinandresen@gmail.com
>>> > wrote:
>>>
>>>> Mike asked what non-0.9 code I'm working on; the three things on the
>>>> top of my list are:
>>>>
>>>> 1) Smarter fee handling on the client side, instead of hard-coded fees.
>>>> I was busy today generating scatter-plots and histograms of transaction
>>>> fees versus priorities to get some insight into what miner policies look
>>>> like right now.
>>>>
>>>> 2) "First double-spend" relaying and alerting, to better support
>>>> low-value in-person transactions.  Related:
>>>> *Have *a *Snack*, Pay with *Bitcoins*<http://www.tik.ee.ethz.ch/file/848064fa2e80f88a57aef43d7d5956c6/P2P2013_093.pdf>
>>>>
>>>>
>>>> 3) Work on 2-3 whitepapers on why we need to increase or remove the 1MB
>>>> block size limit, how we can do it safely, and go through all of the
>>>> arguments that have been made against it and explain why they're wrong.
>>>>
>>>> --
>>>> --
>>>> Gavin Andresen
>>>>
>>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>
>

--089e0160c454580dc804e410d003
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">A ban-subnet RPC would be a reasonable addition, but obvio=
usly DoS attackers that are IP or bandwidth constrained are really just scr=
ipt kiddies. Also anything that involves every node operator doing manual i=
ntervention rather works against decentralisation and having a big network.=
 That&#39;s why I keep pushing for automated heuristic driven prioritisatio=
n.</div>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Fri, Aug 1=
6, 2013 at 3:41 PM, Warren Togami Jr. <span dir=3D"ltr">&lt;<a href=3D"mail=
to:wtogami@gmail.com" target=3D"_blank">wtogami@gmail.com</a>&gt;</span> wr=
ote:<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"><div><a href=3D"https://tog=
ami.com/~warren/archive/2013/example-bitcoind-dos-mitigation-via-iptables.t=
xt" target=3D"_blank">https://togami.com/~warren/archive/2013/example-bitco=
ind-dos-mitigation-via-iptables.txt</a><br>
</div><b>Anti-DoS Low Hanging Fruit: source IP or subnet connection limits<=
/b><div>
<div>If you disallow the same IP and/or subnet from establishing too many T=
CP connections with your node, it becomes more expensive for attackers to u=
se a single host exhaust a target node&#39;s resources. =C2=A0This iptables=
 firewall based example has almost zero drawbacks, but it is too complicate=
d for most people to deploy. =C2=A0Yes, there is a small chance that you wi=
ll block legitimate connections, but there are plenty of other nodes for ra=
ndom connections to choose from. =C2=A0Configurable per source IP and sourc=
e subnet limits with sane defaults enforced by bitcoind itself would be a b=
ig improvement over the current situation where one host address can consum=
e limited resources of many target nodes.</div>

<div><br></div><div>This doesn&#39;t remove the risk of a network-wide conn=
ection exhaustion attack by a determined attacker, but it at least makes mu=
ltiple types of attacks a lot more expensive. =C2=A0This also doesn&#39;t d=
o much against the io vulnerability, which would require major redesigns to=
 prevent in Bitcoin.</div>

<div><br></div><div><a href=3D"https://github.com/litecoin-project/litecoin=
/commit/db4d8e21d99551bef4c807aa1534a074e4b7964d" target=3D"_blank">https:/=
/github.com/litecoin-project/litecoin/commit/db4d8e21d99551bef4c807aa1534a0=
74e4b7964d</a><br>

</div><div><b>Want to safely delay the block size limit increase for anothe=
r year or two?</b> =C2=A0This patch alone enables that.</div><div><br></div=
></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">=
<div>
<div class=3D"h5">On Fri, Aug 16, 2013 at 2:24 AM, Mike Hearn <span dir=3D"=
ltr">&lt;<a href=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.n=
et</a>&gt;</span> wrote:<br>
</div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5"><div dir=
=3D"ltr">The only other thing I&#39;d like to see there is the start of a n=
ew anti-DoS framework. I think once the outline is in place other people wi=
ll be able to fill it in appropriately. But the current framework has to be=
 left behind.<div>


<br></div><div>If I had to choose one thing to evict to make time for that,=
 it&#39;d be the whitepapers. At the moment we still have plenty of headroo=
m in block sizes, even post April. It can probably be safely delayed for a =
while.</div>


</div><div><div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quot=
e">On Fri, Aug 16, 2013 at 2:11 PM, Mike Hearn <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>&gt;</spa=
n> 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">Cool. Maybe it&#39;s time for another development update o=
n the foundation blog?</div><div><div><div class=3D"gmail_extra"><br><br><d=
iv class=3D"gmail_quote">On Fri, Aug 16, 2013 at 3:00 AM, Gavin Andresen <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:gavinandresen@gmail.com" target=3D"_b=
lank">gavinandresen@gmail.com</a>&gt;</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">Mike asked what non-0.9 cod=
e I&#39;m working on; the three things on the top of my list are:<div><br><=
/div>



<div>1) Smarter fee handling on the client side, instead of hard-coded fees=
. I was busy today generating scatter-plots and histograms of transaction f=
ees versus priorities to get some insight into what miner policies look lik=
e right now.</div>




<div><br></div><div>2) &quot;First double-spend&quot; relaying and alerting=
, to better support low-value in-person transactions. =C2=A0Related:=C2=A0<=
/div><h3 style=3D"margin:0px;padding:0px;border:0px;font-weight:normal;font=
-size:16px;font-family:Arial,sans-serif">




<a href=3D"http://www.tik.ee.ethz.ch/file/848064fa2e80f88a57aef43d7d5956c6/=
P2P2013_093.pdf" style=3D"color:rgb(102,17,204);outline:none" target=3D"_bl=
ank"><b style=3D"color:rgb(102,17,204);outline:none">Have=C2=A0</b><font co=
lor=3D"#6611cc">a=C2=A0</font><b style=3D"color:rgb(102,17,204);outline:non=
e">Snack</b><font color=3D"#6611cc">, Pay with=C2=A0</font><b style=3D"colo=
r:rgb(102,17,204);outline:none">Bitcoins</b></a>=C2=A0</h3>




<div><br></div><div>3) Work on 2-3 whitepapers on why we need to increase o=
r remove the 1MB block size limit, how we can do it safely, and go through =
all of the arguments that have been made against it and explain why they&#3=
9;re wrong.<span><font color=3D"#888888"><div class=3D"gmail_extra">




<div><br></div>-- <br>--<br>Gavin Andresen<br>
</div></font></span></div><div class=3D"gmail_extra"><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div><br></div></div><div class=3D"im">-----------------------------=
-------------------------------------------------<br>
Get 100% visibility into Java/.NET code with AppDynamics Lite!<br>
It&#39;s a free troubleshooting tool designed for production.<br>
Get down to code-level detail for bottlenecks, with &lt;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&amp;iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D48897031&amp;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&#39;s a free troubleshooting tool designed for production.<br>
Get down to code-level detail for bottlenecks, with &lt;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&amp;iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D48897031&amp;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>
<br></blockquote></div><br></div>

--089e0160c454580dc804e410d003--