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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gavinandresen@gmail.com>) id 1R4CaX-0001Zo-Ne
for bitcoin-development@lists.sourceforge.net;
Thu, 15 Sep 2011 14:06:49 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.161.47 as permitted sender)
client-ip=209.85.161.47; envelope-from=gavinandresen@gmail.com;
helo=mail-fx0-f47.google.com;
Received: from mail-fx0-f47.google.com ([209.85.161.47])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1R4CaS-00089f-7S
for bitcoin-development@lists.sourceforge.net;
Thu, 15 Sep 2011 14:06:49 +0000
Received: by fxi1 with SMTP id 1so915145fxi.34
for <bitcoin-development@lists.sourceforge.net>;
Thu, 15 Sep 2011 07:06:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.33.19 with SMTP id f19mr595816fad.122.1316095597907; Thu,
15 Sep 2011 07:06:37 -0700 (PDT)
Received: by 10.152.25.105 with HTTP; Thu, 15 Sep 2011 07:06:37 -0700 (PDT)
In-Reply-To: <4E71F6D6.2090208@justmoon.de>
References: <CABsx9T2MKTYCeOqERXKBMYEqNEK4eo9jGt81gZE1=Fv=s3wEqA@mail.gmail.com>
<CANEZrP3FFEK0xrZqQkPyi8uoyb=XiPU7fSJDcGCLxiGH2uh3dQ@mail.gmail.com>
<CABsx9T0Eowp6_mTcggCz3tivRL0NsqyyxqingmPzZ2qkJnU9EA@mail.gmail.com>
<4E71F6D6.2090208@justmoon.de>
Date: Thu, 15 Sep 2011 10:06:37 -0400
Message-ID: <CABsx9T1_rOTd+sSgBTnj2iGKC2t7Rrh_pFAGtmWwjAKxaT0jdQ@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Stefan Thomas <moon@justmoon.de>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.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
(gavinandresen[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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
0.0 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1R4CaS-00089f-7S
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Request review: drop misbehaving peers
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, 15 Sep 2011 14:06:49 -0000
> Should the DoS protection auto-disable if the node has less than a minimum
> number of connections? The idea being that if our node seems to be kicking
> everybody off the roster maybe there is something wrong with the
> protections.
Darn good question. If the protection fails, would it be better for it
to 'fail hard', leaving people complaining "bitcoin won't stay
connected!"
Or fail soft, so you at least have a couple of connections.
I think fail hard is better-- we'll immediately know about the
problem, and can fix it. Fail soft makes me nervous because I think
that would make it more likely a bug splits the network (and,
therefore, the blockchain).
> It would be nice if the node sent a message to the banned peer with a code
> indicating the reason for the ban
If I think you're trying to DoS me, why would I be nice to you? I
think response messages would just give an attacker another potential
attack vector, and it is clear from the debug.log what triggers a ban.
> Should sending lots of messages that don't pass the protocol-level checksum
> test be a bannable offense? Or generally sending garbage data?
Good question. Anybody see a reason not to? How much tolerance (if
any) should there be for sending garbage data (I assume the
lower-level network stack almost never garbles data, is that a good
assumption)?
--
--
Gavin Andresen
|
