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
217
218
219
220
221
222
|
Return-Path: <jgarzik@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 58E33941
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Aug 2015 06:01:09 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com
[209.85.212.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2B801EA
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Aug 2015 06:01:08 +0000 (UTC)
Received: by wicja10 with SMTP id ja10so6932276wic.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 20 Aug 2015 23:01:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=hZ7i2Cu8L/fGU8o4A+DVE1kCEFv3+lSCzfQsIY2RGxw=;
b=QqKMfMNC2cv4PCtcSYE2ZZX38AV6LKKw4Wh7XkSxKy0RLZ+qzxTVzFhaHcRsj9KMih
BaxhtV6/koOIlNejQxBpEbP0SBQLsN+nq+J7nR2ktEPRa2rKUoyO31QAEC4KEwBKm2gZ
wdILvtzBtIWXb/164BQQk/VI5RKCkkL/3EKVyTYnSEu8SmAmk78rW8BnVmhZrUNl4byW
zrNof0H0CYKIQ7PJd+8bysGOamyS/remUnPwAO8lKnCkX17OyKjCt86T5xwdCMeK6anL
/HCLdRlPGiobv/4o++vxfGsf4mIuaUin4DNPbm5Y5CpV4a8DnBGYLAlwA5Maq26RZ4PB
1irw==
MIME-Version: 1.0
X-Received: by 10.180.11.194 with SMTP id s2mr2768336wib.33.1440136866774;
Thu, 20 Aug 2015 23:01:06 -0700 (PDT)
Received: by 10.28.52.84 with HTTP; Thu, 20 Aug 2015 23:01:06 -0700 (PDT)
In-Reply-To: <20150821055534.GA27259@muck>
References: <55D6AD19.10305@mattcorallo.com>
<CADm_WcZJEe4fz4dLYKeOzC0CWbM=-o92BvEF0qiGvNwyMjrEiA@mail.gmail.com>
<20150821055534.GA27259@muck>
Date: Fri, 21 Aug 2015 02:01:06 -0400
Message-ID: <CADm_WcanqF7oHn7huKuYP8iFWmY4XE58tG01M_Nqg9qx6YFu9A@mail.gmail.com>
From: Jeff Garzik <jgarzik@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=001a11c355a25f46d8051dcbfe02
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Revisiting NODE_BLOOM: Proposed BIP
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Aug 2015 06:01:09 -0000
--001a11c355a25f46d8051dcbfe02
Content-Type: text/plain; charset=UTF-8
I don't see any link to data backing up "Bloom filter usage has declined
significantly"
Is there actual data showing this feature's use is declining or
non-existent?
On Fri, Aug 21, 2015 at 1:55 AM, Peter Todd <pete@petertodd.org> wrote:
> On Fri, Aug 21, 2015 at 01:48:23AM -0400, Jeff Garzik via bitcoin-dev
> wrote:
> > If this is widely deployed + enabled, what is the impact to current
> wallets
> > in use?
>
> See my comment on the recently-opened issue, reproduced below. In short,
> not all that much, especially if we adopt my suggestion of having the
> Core implementation accept and respond to bloom filter requests from
> non-upgraded clients regardless of whether or not NODE_BLOOM was set
> until some fixed upgrade deadline in the future.
>
>
> Note that since the last time NODE_BLOOM was proposed, the landcape for
> (lite-)SPV clients has changed significantly in a few key ways:
>
> 1) @mikehearn's [Cartographer](https://github.com/mikehearn/httpseed)
> seed protocol has been created and deployed in production to allow
> (lite-)SPV clients to find nodes supporting arbitrary service bits,
> notable NODE_GETUTXOs.
>
> 2) Bloom filter usage has declined significantly, as lite-SPV clients
> are moving towards using centralized, trusted, servers run by the
> wallet
> authors. For instance
> [Mycelium](https://github.com/mycelium-com/wallet),
> [GreenBits](https://github.com/greenaddress/GreenBits),
> [AirBitz](
> https://www.reddit.com/r/Bitcoin/comments/3etohn/whats_wrong_with_breadwallet/ctirou5
> ),
> and [Electrum](https://electrum.org/#home) all fall in this category.
>
> 3) Bloom filters [have been found](http://eprint.iacr.org/2014/763) to
> have severe privacy issues, offering essentially no privacy at all.
> Under many threat models a small number of trusted servers pose less
> privacy security risk than connecting to random, sybil-attackable,
> peers
> using unencrypted connections and giving those peers very accurate
> wallet contents information.
>
> 4) Finally, Bloom filters still have [unsolved DoS attack
> issues](
> https://www.reddit.com/r/Bitcoin/comments/3hjak7/the_hard_work_of_core_devs_not_xt_makes_bitcoin/cu9xntf?context=3
> ),
> that will get significantly worse under upcoming blocksize increase
> proposals.
>
> Re: service bit identifier, I'd just pick 1<<3
>
> -https://github.com/bitcoin/bitcoin/issues/6578#issuecomment-133226943
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d
>
--001a11c355a25f46d8051dcbfe02
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I don't see any link to data backing up "<span st=
yle=3D"font-size:13px">Bloom filter usage has declined significantly"<=
/span><div><br></div><div>Is there actual data showing this feature's u=
se is declining or non-existent?</div><div><br></div></div><div class=3D"gm=
ail_extra"><br><div class=3D"gmail_quote">On Fri, Aug 21, 2015 at 1:55 AM, =
Peter Todd <span dir=3D"ltr"><<a href=3D"mailto:pete@petertodd.org" targ=
et=3D"_blank">pete@petertodd.org</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><span class=3D"">On Fri, Aug 21, 2015 at 01:48:23AM -0400, Je=
ff Garzik via bitcoin-dev wrote:<br>
> If this is widely deployed + enabled, what is the impact to current wa=
llets<br>
> in use?<br>
<br>
</span>See my comment on the recently-opened issue, reproduced below. In sh=
ort,<br>
not all that much, especially if we adopt my suggestion of having the<br>
Core implementation accept and respond to bloom filter requests from<br>
non-upgraded clients regardless of whether or not NODE_BLOOM was set<br>
until some fixed upgrade deadline in the future.<br>
<br>
<br>
=C2=A0 =C2=A0 Note that since the last time NODE_BLOOM was proposed, the la=
ndcape for<br>
=C2=A0 =C2=A0 (lite-)SPV clients has changed significantly in a few key way=
s:<br>
<br>
=C2=A0 =C2=A0 1) @mikehearn's [Cartographer](<a href=3D"https://github.=
com/mikehearn/httpseed" rel=3D"noreferrer" target=3D"_blank">https://github=
.com/mikehearn/httpseed</a>)<br>
=C2=A0 =C2=A0 seed protocol has been created and deployed in production to =
allow<br>
=C2=A0 =C2=A0 (lite-)SPV clients to find nodes supporting arbitrary service=
bits,<br>
=C2=A0 =C2=A0 notable NODE_GETUTXOs.<br>
<br>
=C2=A0 =C2=A0 2) Bloom filter usage has declined significantly, as lite-SPV=
clients<br>
=C2=A0 =C2=A0 are moving towards using centralized, trusted, servers run by=
the wallet<br>
=C2=A0 =C2=A0 authors. For instance<br>
=C2=A0 =C2=A0 [Mycelium](<a href=3D"https://github.com/mycelium-com/wallet"=
rel=3D"noreferrer" target=3D"_blank">https://github.com/mycelium-com/walle=
t</a>),<br>
=C2=A0 =C2=A0 [GreenBits](<a href=3D"https://github.com/greenaddress/GreenB=
its" rel=3D"noreferrer" target=3D"_blank">https://github.com/greenaddress/G=
reenBits</a>),<br>
=C2=A0 =C2=A0 [AirBitz](<a href=3D"https://www.reddit.com/r/Bitcoin/comment=
s/3etohn/whats_wrong_with_breadwallet/ctirou5" rel=3D"noreferrer" target=3D=
"_blank">https://www.reddit.com/r/Bitcoin/comments/3etohn/whats_wrong_with_=
breadwallet/ctirou5</a>),<br>
=C2=A0 =C2=A0 and [Electrum](<a href=3D"https://electrum.org/#home" rel=3D"=
noreferrer" target=3D"_blank">https://electrum.org/#home</a>) all fall in t=
his category.<br>
<br>
=C2=A0 =C2=A0 3) Bloom filters [have been found](<a href=3D"http://eprint.i=
acr.org/2014/763" rel=3D"noreferrer" target=3D"_blank">http://eprint.iacr.o=
rg/2014/763</a>) to<br>
=C2=A0 =C2=A0 have severe privacy issues, offering essentially no privacy a=
t all.<br>
=C2=A0 =C2=A0 Under many threat models a small number of trusted servers po=
se less<br>
=C2=A0 =C2=A0 privacy security risk than connecting to random, sybil-attack=
able, peers<br>
=C2=A0 =C2=A0 using unencrypted connections and giving those peers very acc=
urate<br>
=C2=A0 =C2=A0 wallet contents information.<br>
<br>
=C2=A0 =C2=A0 4) Finally, Bloom filters still have [unsolved DoS attack<br>
=C2=A0 =C2=A0 issues](<a href=3D"https://www.reddit.com/r/Bitcoin/comments/=
3hjak7/the_hard_work_of_core_devs_not_xt_makes_bitcoin/cu9xntf?context=3D3"=
rel=3D"noreferrer" target=3D"_blank">https://www.reddit.com/r/Bitcoin/comm=
ents/3hjak7/the_hard_work_of_core_devs_not_xt_makes_bitcoin/cu9xntf?context=
=3D3</a>),<br>
=C2=A0 =C2=A0 that will get significantly worse under upcoming blocksize in=
crease<br>
=C2=A0 =C2=A0 proposals.<br>
<br>
=C2=A0 =C2=A0 Re: service bit identifier, I'd just pick 1<<3<br>
<br>
=C2=A0 =C2=A0 -<a href=3D"https://github.com/bitcoin/bitcoin/issues/6578#is=
suecomment-133226943" rel=3D"noreferrer" target=3D"_blank">https://github.c=
om/bitcoin/bitcoin/issues/6578#issuecomment-133226943</a><br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
'peter'[:-1]@<a href=3D"http://petertodd.org" rel=3D"noreferrer" ta=
rget=3D"_blank">petertodd.org</a><br>
00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d<br>
</div></div></blockquote></div><br></div>
--001a11c355a25f46d8051dcbfe02--
|
