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
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
|
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 <pete@petertodd.org>) id 1Wtksp-00075T-OS
for bitcoin-development@lists.sourceforge.net;
Sun, 08 Jun 2014 21:44:07 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.55 as permitted sender)
client-ip=62.13.149.55; envelope-from=pete@petertodd.org;
helo=outmail149055.authsmtp.co.uk;
Received: from outmail149055.authsmtp.co.uk ([62.13.149.55])
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Wtkso-0000PQ-B1 for bitcoin-development@lists.sourceforge.net;
Sun, 08 Jun 2014 21:44:07 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s58LhxIV015131;
Sun, 8 Jun 2014 22:43:59 +0100 (BST)
Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s58LhtS9065323
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Sun, 8 Jun 2014 22:43:58 +0100 (BST)
Date: Sun, 8 Jun 2014 17:45:29 -0400
From: Peter Todd <pete@petertodd.org>
To: Alan Reiner <etotheipi@gmail.com>
Message-ID: <20140608214529.GB4191@savin>
References: <20140606084852.GA30247@netbook.cypherspace.org>
<20140606090441.GA19256@savin>
<20140606104543.GA31085@netbook.cypherspace.org>
<20140606164639.GB14891@savin>
<CAAS2fgTKiPMPOazNTPL8+3Ov1xOj=H+yK3u+sd_pe=nyDSPgTw@mail.gmail.com>
<20140606170524.GA29195@savin>
<CAAS2fgT3CfJ9Lf2H2BYVfUeJoF0RBi+EMmAghj5G2vJPtahmjg@mail.gmail.com>
<20140606174545.GB29195@savin>
<CANEZrP0BEod6b5joJBMPDv_NAxAh9Kio3aniZ3sH6f9Q4nozpQ@mail.gmail.com>
<53936B87.3060804@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="cvVnyQ+4j833TQvp"
Content-Disposition: inline
In-Reply-To: <53936B87.3060804@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: ff6cc3b2-ef55-11e3-b396-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdgoUEkAaAgsB AmIbWVZeVF57XGs7 bAxPbAVDY01GQQRq
WVdMSlVNFUsrBBR9 Xlp9Wxl0cgZEezBx Z0FhWz4NCkIpJkUv
QFMBQ2gDeGZhPWMC AkNRcR5UcAFPdx8U a1UrBXRDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4hGjk7 QlgIFDQzdQAA
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 76.10.178.109/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
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 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1Wtkso-0000PQ-B1
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Bloom bait
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: Sun, 08 Jun 2014 21:44:07 -0000
--cvVnyQ+4j833TQvp
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat, Jun 07, 2014 at 03:44:07PM -0400, Alan Reiner wrote:
>=20
> On 06/07/2014 07:22 AM, Mike Hearn wrote:
> >
> > You can send different bloom filters to different peers too, so I'm
> > not sure why you're listing subsetting as a unique advantage of prefix
> > filters.
> >
> >
>=20
> Please let me know if we've gone down this path before, but it would
> seem that the more different bloom filters you create, the more
> information you give away. It would be most useful to create a single
> bloom filter that captures every address you ever intend to use (say a
> look ahead of 1000 addresses), and then only ever communicate that.=20
> Once people see multiple filters that you produce, they can start
> looking at the intersection of them to reduce the identity space. I
> would expect that after enough bloom variants, they could figure out a
> perfect subset of blockchain addresses in your wallet. (I suppose you
> could intentionally select an extra 20% addresses to include in every
> bloom filter, but it's a hack).
>=20
> Similarly, if you keep updating your bloom filter to include more
> addresses, the difference in what passes through the previous one and
> the new one gives away information about new addresses you created.
You're completely correct. You can use the same nTweak value for each
filter and then slice up the filters bitwise, but then you end up
linking every query you make to your identity unless you just used a
fixed nTweak that everyone else uses. (e.g. zero) If you do that, you
still have the problem that you're greatly increasing the load on the
network.
In any case, all this shows is that in the future bloom filters will
very likely go away eventually, and to make that upgrade path smooth it
only makes sense to define a way for nodes to let others know whether or
not bloom is supported. A NODE_BLOOM service bit is a very reasonable
and simple way to do exactly that, and is defacto what implementations
that don't support bloom filters do anyway.
Note BTW that re: DNS seeds, once the NODE_BLOOM BIP is accepted and the
NODE_BLOOM patch merged into bitcoind, I'll write a patch for sipa's
seeder to make it only return seeds with bloom filter support.
--=20
'peter'[:-1]@petertodd.org
00000000000000003afb1fdf0867fc063775e69f9ae79870bb8727f25b49e88f
--cvVnyQ+4j833TQvp
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQGrBAEBCACVBQJTlNl1XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAzYWZiMWZkZjA4NjdmYzA2Mzc3NWU2OWY5YWU3OTg3MGJi
ODcyN2YyNWI0OWU4OGYvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfvKGggAhLGp3XW8PKyh3LwGm5OFpnpR
W4UoZJtb9hS3zQpzKmLszWLrQLO2NgTujy0tJo3tfPFBZ7Gotz0enMXt+xWtNJyL
Hqnflc4bZOgZ4m3mMnx2akbEt8j4SBcSaagICe3IzafE+oYEIQuVAZKcstv3cWnd
sId1Q5YoTF8HvNlbilw6pp7tFpL9oHrNJ7ier+GOuFtWwgpmWTT8hnRwLyqExkvo
VXPssp9iozJsl1QSLjSXYnWrdpKzAXyBBU2kCW1jhzONu0aqN3oRPh9eLKbRGa3T
HwvTabXhiJlYWObkGHywzU4i3PLsRR1yrQaEHjaAF+OWrrrZdgi9O4pPzDsJTg==
=h87B
-----END PGP SIGNATURE-----
--cvVnyQ+4j833TQvp--
|
