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
|
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 <gavinandresen@gmail.com>) id 1R4EfI-0002TM-74
for bitcoin-development@lists.sourceforge.net;
Thu, 15 Sep 2011 16:19:52 +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 1R4EfH-0004EQ-F9
for bitcoin-development@lists.sourceforge.net;
Thu, 15 Sep 2011 16:19:52 +0000
Received: by fxi1 with SMTP id 1so1109767fxi.34
for <bitcoin-development@lists.sourceforge.net>;
Thu, 15 Sep 2011 09:19:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.63.8 with SMTP id z8mr36733fah.84.1316103585132; Thu, 15
Sep 2011 09:19:45 -0700 (PDT)
Received: by 10.152.25.105 with HTTP; Thu, 15 Sep 2011 09:19:45 -0700 (PDT)
In-Reply-To: <201109151136.47485.luke@dashjr.org>
References: <CABsx9T2MKTYCeOqERXKBMYEqNEK4eo9jGt81gZE1=Fv=s3wEqA@mail.gmail.com>
<201109142206.40455.luke@dashjr.org> <4E71F5F8.2020807@jerviss.org>
<201109151136.47485.luke@dashjr.org>
Date: Thu, 15 Sep 2011 12:19:45 -0400
Message-ID: <CABsx9T2kQTAA77Q=qYc2iKNftQSd8ficfhcXL2W6kX0JUhe3Dw@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: bitcoin-development@lists.sourceforge.net
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 T_TO_NO_BRKTS_FREEMAIL To: misformatted and free email service
-0.0 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1R4EfH-0004EQ-F9
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 16:19:52 -0000
I hate to get specific about potential attacks on a public mailing
list, but I think the debate over what to do with non-standard
transactions means we need to.
I agree with Gregory; if there are NO rules about what transactions
peers can send at you, then an attacker can trivially get around other
the DoS rules.
I also agree we need to think hard about what will happen when new
'standard' transaction types are deployed.
There are two significant DoS attacks I can imagine using transactions
that will never be included in blocks. The "will never be included in
blocks" bit is important, because if an attacker can make you do
significant work at no cost to themselves then they win. And if the
transactions will never be included in blocks the attacker can include
lots of transaction fees that will never be spent.
1) Exhaust memory by filling up the transaction memory pool. I think
another patch needs to be written to deal with that (keep the size of
the transaction pool reasonable by evicting low-priority
transactions).
2) Waste CPU time validating transactions They can make you use an
arbitrary amount of CPU time just by flooding you with a stream of
valid-but-won't-ever-get-into-a-block transactions.
The code already refuses to relay non-standard transactions, and
doesn't check their signatures or add them to the memory pool, so I
think no DoS check is needed for them (and would be harmful when we do
start supporting new standard transactions).
It also drops transactions with "too few fees" before checking
signatures or doing other CPU-intensive work, so no I think no DoS
check is needed there, either (and again, would be harmful when
transaction fee rules change).
I'm ignoring bandwidth DoS attacks-- we already have the
-maxreceivebuffer option to deal with those.
PS: I'll add Gregory's comment:
"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)"
... as a comment in the code so hopefully we don't forget it.
--
--
Gavin Andresen
|
