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
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
|
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 <pete@petertodd.org>) id 1WsxGv-0007uA-J6
for bitcoin-development@lists.sourceforge.net;
Fri, 06 Jun 2014 16:45:41 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.95 as permitted sender)
client-ip=62.13.149.95; envelope-from=pete@petertodd.org;
helo=outmail149095.authsmtp.com;
Received: from outmail149095.authsmtp.com ([62.13.149.95])
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1WsxGt-0001hc-MM for bitcoin-development@lists.sourceforge.net;
Fri, 06 Jun 2014 16:45:41 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s56GjR7L090256;
Fri, 6 Jun 2014 17:45:27 +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 s56GjDvC005083
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Fri, 6 Jun 2014 17:45:16 +0100 (BST)
Date: Fri, 6 Jun 2014 12:46:39 -0400
From: Peter Todd <pete@petertodd.org>
To: Adam Back <adam@cypherspace.org>
Message-ID: <20140606164639.GB14891@savin>
References: <20140606081933.GA29458@savin>
<20140606084852.GA30247@netbook.cypherspace.org>
<20140606090441.GA19256@savin>
<20140606104543.GA31085@netbook.cypherspace.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="l76fUT7nc3MelDdI"
Content-Disposition: inline
In-Reply-To: <20140606104543.GA31085@netbook.cypherspace.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: f059feef-ed99-11e3-9f74-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdgQUEkAaAgsB AmIbWlNeVFh7WGU7 bAxPbAVDY01GQQRq
WVdMSlVNFUsrBBp2 XGpYIRlycgVOezBy Z05iVj4NXEFzIxMo
FFMBQWQPeGZhPWMC WRZfcx5UcAFPdx8U a1N6AHBDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4hGjk7 QlgIFDQzdQAA
X-Authentic-SMTP: 61633532353630.1024: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
0.0 T_FILL_THIS_FORM_SHORT Fill in a short form with personal
information
X-Headers-End: 1WsxGt-0001hc-MM
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: Fri, 06 Jun 2014 16:45:41 -0000
--l76fUT7nc3MelDdI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Jun 06, 2014 at 12:45:43PM +0200, Adam Back wrote:
(changed subject line as this discussion has nothing to do with
NODE_BLOOM)
> As I recall prefix brute forcing was a bit twiddle saving, ie searching f=
or
> EDH key that has the users public prefix. That does not improve privacy
> over an explicit prefix, it saves a byte or so at the expense of average =
128
> EDH exchanges to send and provides also some probably relatively ineffect=
ive
> plausible deniability by enabling the transaction to be indistinguishable
> from some other (not very common) types of transaction.
I think you should re-read my original proposal; there's a whole host of
misunderstandings above, for instance I have no idea where you got the
idea that it has anything to do with "saving a byte" came from, or where
the number 128 came from.
> >don't do that they have privacy equal or better than bloom filters, but
> >with better scalability.
>=20
> either its full node only where prefixes are not used, which is less
> scalable than bloom; or prefixes are used explicitly or implicitly
> (brute-force) and either way privacy is weakened by the extra correlation
> hook provided by elimination from the network graph of payments with
> mismatched prefixes.
Again, you have a misunderstanding. Both bloom filters and prefix
filters are just ways of giving a peer a probabalistic filter to match
transactions against. Where they differ is that bloom filters has O(n)
scaling, where n is the size of a block, and prefix filters have O(log n)
scaling with slightly(1) higher k. Again, if you *don't* use brute forcing
in conjunction with prefixes they have no different transactional graph
privacy than bloom filters, but the better scalability lets you do
things like split your queries across multiple peers that give you
better protection against hostile nodes. Additionally prefix filters
are compatible with future miner committed indexes to make the data
authenticated.
1) see Amir's experience implementing prefix lookup in Obelisk
> We need to consider the two types of privacy involved. Privacy from the
> full node an SPV client is relying on to find its payments, vs privacy fr=
om
> analysis of the public transaction graph.
Agreed
> The latter is more damaging.
Maybe! If adversaries are operating a significant fraction of the peers
you are connecting to the current design of bloom filters + HD wallets
results in situations where those adversaries have better transactional
graph information than the alternative.
> Better to design for privacy against future analysis of
> public info, than
> privacy by argument to select non-hostile nodes. Tor has changed recently
> to account for the fact that chosing fresh random nodes is actually
> worse. ie you have a probability of identity/address identification
> per route/node,
> and repeatedly selecting routes/nodes just cumulatively increases the cha=
nce
> you'll be identified. Better to pick a random node, identify it and stick
> to it and hope you chose well.
That's basically what Electrum and Obelisk already do - by default you
connect to a relatively small set of blockchain data servers operated by
well known people and use the same server repeatedly.
Applying that to the P2P network however is tricky as there is a huge
amount of churn in the nodes:
#bitcoin-dev/14/06/14-06-06.log:11:18 < hearn> bitcoinj can't use
[service bits] as it relies on DNS seeds and that is unlikely to change
any time soon due to the general churn rate in the network making it
hard to bootstrap quickly using just remembered sets of IPs.
> Maybe other simpler, but yes there was the proof of concept that the math
> exists in the form of the weil pairing.
>=20
> https://bitcointalk.org/index.php?topic=3D431756.new
I know, where can I find running code? Remember that a bug can easily
lose thousands of dollars worth of Bitcoins.
--=20
'peter'[:-1]@petertodd.org
00000000000000001d2af1653c415b7801ce4c9b18ac7e87bef597e652b203e6
--l76fUT7nc3MelDdI
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQGrBAEBCACVBQJTkfBrXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAxNzhhZDVlNmY3YjM1MzVjNjEwNmI3YzZmMGJkZWI4MzFk
YmQ4OWM2NDJiNmYyNzEvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfuJywf/Rj4CXObu9DlW4CvmhSsaa9jr
Q8wcaI2VK7zSDoZFn5XsmyL4rXRov8y9s/VtPrja98aSErxLY8BGjiJVM5fh2kbS
XZ02Hi8VxwKevNexVQW3XzKM1wj7vbm4JXn+cHkfj+NDKzR+QcZqgx95LB3XvRK4
fSnkWakzDrpvrR5PC/XGOiAYhpg1HWXYAvaflmeiO33Y/82Bj3yrjxq14RbkHjo/
262LAZJ0SHD7d3S0B/53Jg9qHM79HkJEmIu8q/qAOdczv6VDhYnWQRuYBPoNip2c
j/bFC8qI4QfqqFuZpadpHjNLivGIB1vw/szCpBwds6E5Janm2LMdCROezaj00w==
=wJw+
-----END PGP SIGNATURE-----
--l76fUT7nc3MelDdI--
|
