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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
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 1UzoPS-0002qQ-Lh
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Jul 2013 13:38:18 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.47 as permitted sender)
client-ip=209.85.219.47; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f47.google.com;
Received: from mail-oa0-f47.google.com ([209.85.219.47])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UzoPR-00021v-0t
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Jul 2013 13:38:18 +0000
Received: by mail-oa0-f47.google.com with SMTP id m1so4095495oag.20
for <bitcoin-development@lists.sourceforge.net>;
Thu, 18 Jul 2013 06:38:11 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.230.163 with SMTP id sz3mr7430622obc.81.1374154691662;
Thu, 18 Jul 2013 06:38:11 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.23.36 with HTTP; Thu, 18 Jul 2013 06:38:11 -0700 (PDT)
In-Reply-To: <20130718121307.GA6062@savin>
References: <CANEZrP2jmWkDbpJEm0vd2CKF-prFNbz_ZeNJfDWtSCKb8k5ZXA@mail.gmail.com>
<2BDA0943-22BB-4405-9AF0-86FB41FD04A6@include7.ch>
<CANEZrP0McSrVzwv=-qimPyX41EEDmyQdYW5QjPr_i+KWyJZSZw@mail.gmail.com>
<2F20A509-13A9-4C84-86D7-A15C21BACD53@include7.ch>
<CANEZrP2yQvmvwP_ZULdS2i+X6L9MeZ+DfidiuZPD2EHwLsN2MA@mail.gmail.com>
<2A1C412D-414E-4C41-8E20-F0D21F801328@grabhive.com>
<CANEZrP12V_5Ak0f91RsMziuqXysde102rGeSko=qPBjefy3AeA@mail.gmail.com>
<8EE501AA-1601-4C28-A32E-80F17D219D3A@grabhive.com>
<20130717105853.GA10083@savin>
<CANEZrP02oQ7GqJfLbEeD+khSGCyFz3eiynPkhARniEWr1ikmPQ@mail.gmail.com>
<20130718121307.GA6062@savin>
Date: Thu, 18 Jul 2013 15:38:11 +0200
X-Google-Sender-Auth: IzIFCZBX0Nc64AxNTDz-cn1ZVO8
Message-ID: <CANEZrP14Xmv4mih1VzP8U51NtSQ=Tuv7ewNNZmG+-pDd+BGdQQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=001a11c2f63a435a9204e1c952ff
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: 1UzoPR-00021v-0t
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] SPV bitcoind? (was: Introducing
BitcoinKit.framework)
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, 18 Jul 2013 13:38:18 -0000
--001a11c2f63a435a9204e1c952ff
Content-Type: text/plain; charset=UTF-8
> SPV clients behaving normally are highly abusive: they use up maximum
> node resources with minimum cost to themselves.
>
This must be a new use of the word "abuse" I haven't come across before :)
At any rate, some of these assumptions are incorrect. Botnets of
compromised web servers are quite common, and asymmetry in node resources
is obviously biased against the kinds of devices people increasingly have
(phones, tablets) where extremely limited memory bandwidth is common and
apps routinely have just 16 or 32mb of memory to do everything including
the GUI.
A good anti-DoS strategy looks much the same as a good load shedding
strategy. There's little reason to treat them separately. Perhaps instead
of talking about DoS we should instead talk about what happens if Bitcoin
suddenly gets too popular. Now there are suddenly lots of good users all
wanting to use the network, and not enough nodes to support them all. What
do we do?
Some rules seem obvious - try to prioritise existing users over new users,
old coins over new coins (dPriority already does this) etc. If you run out
of TCP sockets prefer to disconnect recent connections (probably new users)
to long lived connections (probably high powered backbone peers). If you
run out of disk seeks prefer processing new blocks to serving old parts of
the chain, etc.
--001a11c2f63a435a9204e1c952ff
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">SPV clients behaving normally are highly abu=
sive: they use up maximum<br>
node resources with minimum cost to themselves.<br></blockquote><div><br></=
div><div>This must be a new use of the word "abuse" I haven't=
come across before :)</div><div><br></div><div>At any rate, some of these =
assumptions are incorrect. Botnets of compromised web servers are quite com=
mon, and asymmetry in node resources is obviously biased against the kinds =
of devices people increasingly have (phones, tablets) where extremely limit=
ed memory bandwidth is common and apps routinely have just 16 or 32mb of me=
mory to do everything including the GUI.</div>
<div><br></div><div>A good anti-DoS strategy looks much the same as a good =
load shedding strategy. There's little reason to treat them separately.=
Perhaps instead of talking about DoS we should instead talk about what hap=
pens if Bitcoin suddenly gets too popular. Now there are suddenly lots of g=
ood users all wanting to use the network, and not enough nodes to support t=
hem all. What do we do?</div>
<div><br></div><div>Some rules seem obvious - try to prioritise existing us=
ers over new users, old coins over new coins (dPriority already does this) =
etc. If you run out of TCP sockets prefer to disconnect recent connections =
(probably new users) to long lived connections (probably high powered backb=
one peers). If you run out of disk seeks prefer processing new blocks to se=
rving old parts of the chain, etc.</div>
</div></div></div>
--001a11c2f63a435a9204e1c952ff--
|
