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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1R4Cp8-0007JL-Ht
for bitcoin-development@lists.sourceforge.net;
Thu, 15 Sep 2011 14:21:54 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.175 as permitted sender)
client-ip=209.85.216.175; envelope-from=gmaxwell@gmail.com;
helo=mail-qy0-f175.google.com;
Received: from mail-qy0-f175.google.com ([209.85.216.175])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1R4Cp4-00039N-GG
for bitcoin-development@lists.sourceforge.net;
Thu, 15 Sep 2011 14:21:54 +0000
Received: by qyk10 with SMTP id 10so5375987qyk.13
for <bitcoin-development@lists.sourceforge.net>;
Thu, 15 Sep 2011 07:21:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.224.176.72 with SMTP id bd8mr952519qab.296.1316096504811; Thu,
15 Sep 2011 07:21:44 -0700 (PDT)
Received: by 10.229.49.12 with HTTP; Thu, 15 Sep 2011 07:21:44 -0700 (PDT)
In-Reply-To: <CABsx9T1_rOTd+sSgBTnj2iGKC2t7Rrh_pFAGtmWwjAKxaT0jdQ@mail.gmail.com>
References: <CABsx9T2MKTYCeOqERXKBMYEqNEK4eo9jGt81gZE1=Fv=s3wEqA@mail.gmail.com>
<CANEZrP3FFEK0xrZqQkPyi8uoyb=XiPU7fSJDcGCLxiGH2uh3dQ@mail.gmail.com>
<CABsx9T0Eowp6_mTcggCz3tivRL0NsqyyxqingmPzZ2qkJnU9EA@mail.gmail.com>
<4E71F6D6.2090208@justmoon.de>
<CABsx9T1_rOTd+sSgBTnj2iGKC2t7Rrh_pFAGtmWwjAKxaT0jdQ@mail.gmail.com>
Date: Thu, 15 Sep 2011 10:21:44 -0400
Message-ID: <CAAS2fgRUv48Fnx4iDkjMeWxsqOVfN0nig37GRpG16bMKQgYaRg@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.4 (-)
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
(gmaxwell[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.2 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1R4Cp4-00039N-GG
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:21:54 -0000
On Thu, Sep 15, 2011 at 10:06 AM, Gavin Andresen
<gavinandresen@gmail.com> wrote:
> If I think you're trying to DoS me, why would I be nice to you? =C2=A0I
> think response messages would just give an attacker another potential
> attack vector, and it is clear from the debug.log what triggers a ban.
Fail hard, log the reason locally. Problem becomes tractable. Also,
for any problem big enough to cause a network outage the issue won't
be reproducibility.
I support the imposition of txn rules=E2=80=94 otherwise the dropping is
nearly pointless due to the hole that any attack can just take the
form of junk txn=E2=80=94 but you must be super careful that an attack can'=
t
be transitive: There should be nothing I can give a node that it will
forward on that will make that node's peers drop it. (and this needs
to remain true while forwarding rules evolve)
So, I'd suggest that you'd only drop on transactions that would
invalidate a block if included in it but the problem there is that
double spends meet that criteria. Better would, perhaps be something
like "would invalidate a block if included; except that double spends
after the last checkpoint are allowed, and nodes should not forward
any txn until they are current with their last checkpoint"
(That bit of complexity is to reduce exposure where a new node gets
hit with double spends that its yet too stupid to reject, and it
forwards them onto its friendly peers who then hang up on it thus
prolonging its period of ignorance=E2=80=94 in general care needs to be tak=
en
to avoid hanging up on nodes that are just too young to know better)
> Good question. Anybody see a reason not to? =C2=A0How 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)?
It would be fine to hang up on any garbage data: something is
obviously wrong. I'd be hesitant to ban on a single instance of it,
it's rare but happens. (e.g. see
http://citeseerx.ist.psu.edu/viewdoc/download?doi=3D10.1.1.14.150&rep=3Drep=
1&type=3Dps)
|
