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
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1YPBIx-0004Vv-Hu
for bitcoin-development@lists.sourceforge.net;
Sat, 21 Feb 2015 14:45:15 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.43 as permitted sender)
client-ip=74.125.82.43; envelope-from=mh.in.england@gmail.com;
helo=mail-wg0-f43.google.com;
Received: from mail-wg0-f43.google.com ([74.125.82.43])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YPBIv-00007k-VF
for bitcoin-development@lists.sourceforge.net;
Sat, 21 Feb 2015 14:45:15 +0000
Received: by mail-wg0-f43.google.com with SMTP id z12so18118701wgg.2
for <bitcoin-development@lists.sourceforge.net>;
Sat, 21 Feb 2015 06:45:08 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.82.129 with SMTP id i1mr4395156wiy.77.1424529907970;
Sat, 21 Feb 2015 06:45:07 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.194.188.11 with HTTP; Sat, 21 Feb 2015 06:45:07 -0800 (PST)
In-Reply-To: <CALqxMTHqrYvYcGDsKkwwSrJ7J0qr_kBjKHmFgO4Bmmkodydw0g@mail.gmail.com>
References: <CALqxMTE2doZjbsUxd-e09+euiG6bt_J=_BwKY_Ni3MNK6BiW1Q@mail.gmail.com>
<CANEZrP32M-hSU-a1DA5aTQXsx-6425sTeKW-m-cSUuXCYf+zuQ@mail.gmail.com>
<CALqxMTFNdtUup5MB2Dc_AmQ827sM-t5yx7WQubbfOEd_bO_Ong@mail.gmail.com>
<CANEZrP0cOY5Wt_mvBSdGGmi4NfZi04SQ7d6GLpnRxmqvXNArGA@mail.gmail.com>
<CALqxMTE1OANaMAvqrcOLuKtYd_jmqYp5GcB4CX77S8+fR05=jg@mail.gmail.com>
<CAAS2fgSsXDTzxS29_SZvy1_Tie8=EGDhUjGkyGTXbc=47ta20w@mail.gmail.com>
<CANEZrP2XoVL6sWxA5KpsGsNxXi-hwdVN=BqXJfn17N-W0_SHEg@mail.gmail.com>
<CALqxMTETmkF3j0YpfMLYhLGwwd7Nw7Qu3kR80D3pjTn_g5+Xxw@mail.gmail.com>
<CANEZrP0nAmhe_jPh5GYD1gX1FLop6zsw+MyXsYizHBR=enfT9g@mail.gmail.com>
<CALqxMTHqrYvYcGDsKkwwSrJ7J0qr_kBjKHmFgO4Bmmkodydw0g@mail.gmail.com>
Date: Sat, 21 Feb 2015 15:45:07 +0100
X-Google-Sender-Auth: 9AAX5U1Er0GDDQ2cC5S2pAtL_zc
Message-ID: <CANEZrP1feonDYtC0J2w12bV_59fBsmJkKkPN7oM1=WMqSZx2jw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Adam Back <adam@cypherspace.org>
Content-Type: multipart/alternative; boundary=f46d044280fa22f920050f9a371f
X-Spam-Score: -0.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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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
X-Headers-End: 1YPBIv-00007k-VF
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] bloom filtering, privacy
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: Sat, 21 Feb 2015 14:45:15 -0000
--f46d044280fa22f920050f9a371f
Content-Type: text/plain; charset=UTF-8
>
> For downloading transactions unless you frequently receive
> transactions you wont be fetching every block. Or are you assuming
> bloom filters dialled up to the point of huge false positives? You
> said otherwise.
>
Well, what I mean is, bitcoinj already gets criticised for having very low
FP rates, but even with those rates we're applying them to hundreds of
thousands of transactions per sync. So it's still enough FPs to trigger at
least one per block, often several, yet people tell us this isn't enough to
give meaningful privacy.
> Relatedly I think bitcoin could do with a store-and-forward message
> bus with privacy and strong reliability via redundancy (but less
> redundancy maybe than consensus all-nodes must receiving and agree and
> store forever).
>
Yup, see here:
https://www.bitcoinauthenticator.org/subspace/
https://groups.google.com/forum/#!topic/bitcoinj/_S15jo5mcDI
Subspace looks like it's developing into what we need.
> You seem to be saying at one point that Tor is useless against
> pervasive eavesdropper threat model
No, Tor is effective against in that threat model. What I meant is that
without Tor, someone doing wire intercepts isn't going to be fazed by using
multiple peers together, and with Tor it's not clear that syncing from
multiple peers in parallel gives much an additional win.
Also, getting Tor practical enough to activate by default is tricky. Though
the same people who are doing Subspace are trying it out to see what
happens.
secondly that other types of attackers are disinterested (how do we know
> that?) or maybe that you
> dont care about privacy vs them (maybe some users do!)
>
Some of my opinions are based on experience of HTTPS deployments, where
many of the same issues apply.
> It would certainly be nice to get real privacy from a wider range of
> attackers but nothing (current situation) is clearly worse; using
> block bloom filters we'd make the pervasive case harder work, and the
> nosy full node learn nothing.
Yes, but what's the best way to fix that?
The calculation goes like this: we have ~80 hours of hacking time to spend
on privacy this quarter. Do we:
a) Do wire encryption
b) Make Bloom filter clients smarter
c) Optimise Tor
d) Do a new PIR protocol from scratch and possibly run out of time having
failed to launch
Of these (d) is the least appealing to me, especially because I don't feel
like submitting SPV related stuff to Bitcoin Core any more. If I were to
work on the protocol it'd be in the context of Bitcoin XT, which rules out
consensus changes or other things that rely on miners. Wire encryption
would probably raise the bar for our spooky friends quite a lot, with
minimal effort. The ROI looks good, compared to more complex PIR.
--f46d044280fa22f920050f9a371f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex">For downloading transactions unless you frequently receive<br>
transactions you wont be fetching every block.=C2=A0 Or are you assuming<br=
>
bloom filters dialled up to the point of huge false positives?=C2=A0 You<br=
>
said otherwise.<br></blockquote><div><br></div><div>Well, what I mean is, b=
itcoinj already gets criticised for having very low FP rates, but even with=
those rates we're applying them to hundreds of thousands of transactio=
ns per sync. So it's still enough FPs to trigger at least one per block=
, often several, yet people tell us this isn't enough to give meaningfu=
l privacy.</div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(2=
04,204,204);border-left-style:solid;padding-left:1ex">Relatedly I think bit=
coin could do with a store-and-forward message<br>
bus with privacy and strong reliability via redundancy (but less<br>
redundancy maybe than consensus all-nodes must receiving and agree and<br>
store forever).=C2=A0<br></blockquote><div><br></div><div>Yup, see here:</d=
iv><div><br></div><div><a href=3D"https://www.bitcoinauthenticator.org/subs=
pace/">https://www.bitcoinauthenticator.org/subspace/</a><br></div><div><a =
href=3D"https://groups.google.com/forum/#!topic/bitcoinj/_S15jo5mcDI">https=
://groups.google.com/forum/#!topic/bitcoinj/_S15jo5mcDI</a></div><div><br><=
/div><div>Subspace looks like it's developing into what we need.</div><=
div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-le=
ft-style:solid;padding-left:1ex">You seem to be saying at one point that To=
r is useless against<br>
pervasive eavesdropper threat model</blockquote><div><br></div><div>No, Tor=
is effective against in that threat model. What I meant is that without To=
r, someone doing wire intercepts isn't going to be fazed by using multi=
ple peers together, and with Tor it's not clear that syncing from multi=
ple peers in parallel gives much an additional win.</div><div><br></div><di=
v>Also, getting Tor practical enough to activate by default is tricky. Thou=
gh the same people who are doing Subspace are trying it out to see what hap=
pens.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204)=
;border-left-style:solid;padding-left:1ex">secondly that other types of=C2=
=A0attackers are disinterested (how do we know that?) or maybe that you<br>
dont care about privacy vs them (maybe some users do!)<br></blockquote><div=
><br></div><div>Some of my opinions are based on experience of HTTPS deploy=
ments, where many of the same issues apply.</div><div>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-le=
ft:1ex">It would certainly be nice to get real privacy from a wider range o=
f<br>
attackers but nothing (current situation) is clearly worse; using<br>
block bloom filters we'd make the pervasive case harder work, and the<b=
r>
nosy full node learn nothing.</blockquote><div><br></div><div>Yes, but what=
's the best way to fix that?</div><div><br></div><div>The calculation g=
oes like this: =C2=A0we have ~80 hours of hacking time to spend on privacy =
this quarter. Do we:</div><div><br></div><div>a) Do wire encryption</div><d=
iv>b) Make Bloom filter clients smarter</div><div>c) Optimise Tor</div><div=
>d) Do a new PIR protocol from scratch and possibly run out of time having =
failed to launch</div><div><br></div><div>Of these (d) is the least appeali=
ng to me, especially because I don't feel like submitting SPV related s=
tuff to Bitcoin Core any more. If I were to work on the protocol it'd b=
e in the context of Bitcoin XT, which rules out consensus changes or other =
things that rely on miners. Wire encryption would probably raise the bar fo=
r our spooky friends quite a lot, with minimal effort. The ROI looks good, =
compared to more complex PIR.</div></div></div></div>
--f46d044280fa22f920050f9a371f--
|
