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
|
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 <gavinandresen@gmail.com>) id 1TR7Zi-0002TV-Du
for bitcoin-development@lists.sourceforge.net;
Wed, 24 Oct 2012 20:29:14 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.53 as permitted sender)
client-ip=74.125.82.53; envelope-from=gavinandresen@gmail.com;
helo=mail-wg0-f53.google.com;
Received: from mail-wg0-f53.google.com ([74.125.82.53])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1TR7Zh-0006Pz-CU
for bitcoin-development@lists.sourceforge.net;
Wed, 24 Oct 2012 20:29:14 +0000
Received: by mail-wg0-f53.google.com with SMTP id dr1so587804wgb.10
for <bitcoin-development@lists.sourceforge.net>;
Wed, 24 Oct 2012 13:29:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.200.150 with SMTP id z22mr9778128wen.97.1351110547300;
Wed, 24 Oct 2012 13:29:07 -0700 (PDT)
Received: by 10.194.27.136 with HTTP; Wed, 24 Oct 2012 13:29:07 -0700 (PDT)
In-Reply-To: <CANEZrP1AFL6ZbV7Njr1s8ggsZkQA1dv_3LYT3z+y83UKqn7Kgg@mail.gmail.com>
References: <CANEZrP0XALwBFJyZTzYd5xBp4MRrjv0s_y2tOXbO7UgjWF2HzA@mail.gmail.com>
<20121024162255.GA30290@vps7135.xlshosting.net>
<CANEZrP1sxtOb+czMtBTkmzngEwMYRqD667WyKQkAOKLi+mGBGQ@mail.gmail.com>
<20121024171104.GA31766@vps7135.xlshosting.net>
<CABsx9T0JyFJKLWK09NEzDk6B9Z2Yz7T55kf8GJ2o3ViCnBpRAw@mail.gmail.com>
<CANEZrP1AFL6ZbV7Njr1s8ggsZkQA1dv_3LYT3z+y83UKqn7Kgg@mail.gmail.com>
Date: Wed, 24 Oct 2012 16:29:07 -0400
Message-ID: <CABsx9T2Oc+LeJjczG_U9u06gkQRmSP0J8Q_hEJv0oGQLnKFuJw@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.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
(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.1 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1TR7Zh-0006Pz-CU
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Draft BIP for Bloom filtering
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: Wed, 24 Oct 2012 20:29:14 -0000
On Wed, Oct 24, 2012 at 3:10 PM, Mike Hearn <mike@plan99.net> wrote:
> Bitcoin already keeps track of which nodes have seen what to avoid redundant
> inv announcements.
Oops, right. That memory usage is bounded right now by bounds on the
memory pool size, though, right? (I'm being lazy and not digging into
that code)
What is the worst-case for an attacker interested in trying to get you
to saturate your upstream bandwidth or use lots of memory? Set a
bloom filter that matches everything, and then start requesting old
blocks in the chain? It would be nice if the worst-case was no worse
than the worst-case we've got now (... requesting full, old
blocks...).
--
--
Gavin Andresen
|
