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
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 2F1AE7F6
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 27 Jul 2019 16:10:08 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.bluematt.me (mail.bluematt.me [69.59.18.99])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 35668FE
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 27 Jul 2019 16:10:05 +0000 (UTC)
Received: from [192.168.1.67] (unknown [69.59.18.155])
by mail.bluematt.me (Postfix) with ESMTPSA id 8CA3082CA3;
Sat, 27 Jul 2019 16:10:03 +0000 (UTC)
Content-Type: multipart/alternative;
boundary=Apple-Mail-FE382715-0483-4F15-993C-AB8315ADCD40
Mime-Version: 1.0 (1.0)
From: Matt Corallo <lf-lists@mattcorallo.com>
X-Mailer: iPhone Mail (16G77)
In-Reply-To: <0DD0A8C8-374E-4E4F-AB08-C51612A28E16@jonasschnelli.ch>
Date: Sat, 27 Jul 2019 12:10:03 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <4661BB32-3725-4E10-9698-25CDBA2F7ACB@mattcorallo.com>
References: <59fad2b6-9b15-ffec-116e-91d27ce29f80@mattcorallo.com>
<qh2qj1$7sg4$1@blaine.gmane.org> <qh76ln$41ag$1@blaine.gmane.org>
<0DD0A8C8-374E-4E4F-AB08-C51612A28E16@jonasschnelli.ch>
To: Jonas Schnelli <dev@jonasschnelli.ch>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,
MIME_QP_LONG_LINE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sat, 27 Jul 2019 20:17:43 +0000
Cc: Andreas Schildbach <andreas@schildbach.de>
Subject: Re: [bitcoin-dev] Bitcoin Core to disable Bloom-based Filtering by
default
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Sat, 27 Jul 2019 16:10:08 -0000
--Apple-Mail-FE382715-0483-4F15-993C-AB8315ADCD40
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
This conversation went off the rails somewhat. I don't think there's any imm=
ediate risk of NODE_BLOOM peers being unavailable. This is a defaults change=
, not a removal of the code to serve BIP 37 peers (nor would I suggest remov=
ing said code while people still want to use them - the maintenance burden i=
sn't much). Looking at historical upgrade cycles, ignoring any other factors=
, there will be a large number of nodes serving NODE_BLOOM for many years.
Even more importantly, if you need them, run a node or two. As long as no on=
e is exploiting the issues with them such a node isn't *too* expensive. Or d=
on't, I guarantee you chainanalysis or some competitor of theirs will very v=
ery happily serve bloom-filtered clients as long as such clients want to dea=
nonymize themselves. We already see a plurality of nodes on the network are c=
learly not run-of-the-mill Core nodes, many of which are likely deanonimizat=
ion efforts.
In some cases BIP 137 is a replacement, in some cases, indeed, it is not. I a=
gree at a protocol level we shouldn't be passing judgement about how users w=
ish to interact with the Bitcoin system (aside from not putting our own, per=
sonal, effort into building such things) but that isn't what's happening her=
e. This is an important DoS fix for the average node, and I don't really und=
erstand the argument that this is going to break existing BIP 37 wallets, bu=
t if it makes you feel any better I can run some beefy BIP 37 nodes.
Matt
> On Jul 26, 2019, at 06:04, Jonas Schnelli via bitcoin-dev <bitcoin-dev@lis=
ts.linuxfoundation.org> wrote:
>=20
>=20
>> 1) It causes way too much traffic for mobile users, and likely even too
>> much traffic for fixed lines in not so developed parts of the world.
>=20
> Yes. It causes more traffic than BIP37.
> Basic block filters for current last ~7 days (1008 blocks) are about 19MB (=
just the filters).
> On top, you will probably fetch a handful of irrelevant blocks due to the =
FPs and due to true relevant txns.
> A over-the-thumb estimation: ~25MB per week of catch-up.
> If you where offline for a month: ~108MB
>=20
> Thats certainly more then BIP37 BF (measured 1.6MB total traffic with andr=
oid schildbach wallet restore blockchain for 8 week [7 weeks headers, 1week m=
erkleblocks]).
>=20
> But lets look at it like this: for an additional, say 25MB per week (maybe=
a bit more), you get the ability to filter blocks without depending on serv=
ing peers who may compromise your financial privacy.
> Also, if you keep the filters, further rescans do consume the same or less=
bandwidth than BF BIP37.
> In other words: you have the chance to potentially increase privacy by con=
suming bandwidth in the range of a single audio podcast per week.
>=20
> I would say the job of protocol developers is protect users privacy where i=
t=E2=80=99s possible (as a default).
> It=E2=80=99s probably a debatable point wether 25MB per week of traffic is=
worth a potential increase in privacy, though I absolutely think 25MB/week i=
s an acceptable tradeoff.
> Saving traffic is possible by using BIP37 or stratum/electrum=E2=80=A6 but=
developers should make sure users are __warned about the consequences__!
>=20
> Additionally, it looks like, peer operators are not endless being willing t=
o serve =E2=80=93 for free =E2=80=93 a CPU/disk intense service with no bene=
fits for the network. I would question wether a decentralised form of BIP37 i=
s sustainable in the long run (if SPV wallet provider bootstrap a net range o=
f NODE_BLOOM peers to make it more reliable on the network would be snake-oi=
l).
>=20
>=20
>>=20
>> 2) It filters blocks only. It doesn't address unconfirmed transactions.
>=20
> Well, unconfirmed transaction are uncertain for various reasons.
>=20
> BIP158 won't allow you to filter the mempool.
> But as soon as you are connected to the network, you may fetch tx with inv=
/getdata and pick out the relevant ones (causes also traffic).
> Unclear and probably impossible with the current BIP158 specs to fetch tra=
nsactions that are not in active relay and are not in a block (mempool txns,=
at least this is true with the current observed relay tactics).
>=20
>=20
>> 3) Afaik, it enforces/encourages address re-use. This stems from the
>> fact that the server decides on the filter and in particular on the
>> false positive rate. On wallets with many addresses, a hardcoded filter
>> will be too blurry and thus each block will be matched. So wallets that
>> follow the "one address per incoming payment" pattern (e.g. HD wallets)
>> at some point will be forced to wrap their key chains back to the
>> beginning. If I'm wrong on this one please let me know.
>=20
> I=E2=80=99m probably the wrong guy to ask (haven=E2=80=99t made the number=
s) but last time I rescanned a Core wallet (in my dev branch) with block fil=
ters (and a Core wallet has >2000 addresses by default) it fetched a low and=
acceptable amount of false positive blocks.
> (Maybe someone who made the numbers step in here.)
>=20
> Though, large wallets =E2=80=93 AFAIK =E2=80=93 also operate badly with BI=
P37.
>=20
>>=20
>> 4) The filters are not yet committed to the blockchain. Until that
>> happens we'd have to trust a server to provide correct filters.
>=20
> I wouldn=E2=80=99t say so. It=E2=80=99s on a similar level than BIP37.
> BIP37 is not =E2=80=93 and can not =E2=80=93 be committed to the blockchai=
n.
> You fully trust the peer that it won=E2=80=99t=E2=80=A6
> a) create fake unconfirmed transactions (would be the same if a BIP158 wal=
let would show you unconfirmed transaction)
> b) lies by omission (you will miss relevant transactions, eventually swipe=
your wallet and loose coins)
>=20
> IMO, the point b) is true for BIP37 and BIP158 (as long as not commited).
> In both cases, you can reduce the trust by comparing between peers / filte=
r-providers.
>=20
> b) is conceptually solvable with a soft-fork (commitment) in BIP158 (not w=
ith BIP37).
>=20
> Additionally, block-filters will, very likely, be useful for other feature=
s (load/rescan an [old] wallet on a prune peer that has the filters construc=
ted).
>=20
>=20
>=20
> There is probably no clear answer like =E2=80=9EX is better than Y=E2=80=9C=
.
>=20
> Personally I would like to see developers being more honest/transparent to=
users about the implications of the used filtering,... and giving them choi=
ces.
> Imagine a user can choose between =E2=80=9EElectrum / BIP37 / BIP158=E2=80=
=9C depending on his needs for privacy and availability of bandwidth. Eventu=
ally also taking the future usage of this wallet (will he load old private k=
eys, will he receive money daily, etc.) into account.
>=20
> Plus, full node hardware appliances that run at home (or in a trusted envi=
ronment) are solving many of these issues plus adding a bunch of great featu=
res =E2=80=93 if done right.
>=20
> /jonas
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--Apple-Mail-FE382715-0483-4F15-993C-AB8315ADCD40
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div dir=3D"ltr"></div><div dir=3D"ltr">Thi=
s conversation went off the rails somewhat. I don't think there's any immedi=
ate risk of NODE_BLOOM peers being unavailable. This is a defaults change, n=
ot a removal of the code to serve BIP 37 peers (nor would I suggest removing=
said code while people still want to use them - the maintenance burden isn'=
t much). Looking at historical upgrade cycles, ignoring any other factors, t=
here will be a large number of nodes serving NODE_BLOOM for many years.</div=
><div dir=3D"ltr"><br></div><div dir=3D"ltr">Even more importantly, if you n=
eed them, run a node or two. As long as no one is exploiting the issues with=
them such a node isn't *too* expensive. Or don't, I guarantee you chainanal=
ysis or some competitor of theirs will very very happily serve bloom-filtere=
d clients as long as such clients want to deanonymize themselves. We already=
see a plurality of nodes on the network are clearly not run-of-the-mill Cor=
e nodes, many of which are likely deanonimization efforts.</div><div dir=3D"=
ltr"><br></div><div dir=3D"ltr">In some cases BIP 137 is a replacement, in s=
ome cases, indeed, it is not. I agree at a protocol level we shouldn't be pa=
ssing judgement about how users wish to interact with the Bitcoin system (as=
ide from not putting our own, personal, effort into building such things) bu=
t that isn't what's happening here. This is an important DoS fix for the ave=
rage node, and I don't really understand the argument that this is going to b=
reak existing BIP 37 wallets, but if it makes you feel any better I can run s=
ome beefy BIP 37 nodes.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">Mat=
t</div><div dir=3D"ltr"><br>On Jul 26, 2019, at 06:04, Jonas Schnelli via bi=
tcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco=
in-dev@lists.linuxfoundation.org</a>> wrote:<br><br></div><blockquote typ=
e=3D"cite"><div dir=3D"ltr"><meta http-equiv=3D"Content-Type" content=3D"tex=
t/html; charset=3Dutf-8"><br class=3D""><div><blockquote type=3D"cite" class=
=3D""><div class=3D""><span style=3D"caret-color: rgb(0, 0, 0); font-family:=
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; f=
ont-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0=
px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-te=
xt-stroke-width: 0px; text-decoration: none; float: none; display: inline !i=
mportant;" class=3D"">1) It causes way too much traffic for mobile users, an=
d likely even too</span><br style=3D"caret-color: rgb(0, 0, 0); font-family:=
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; f=
ont-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0=
px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-te=
xt-stroke-width: 0px; text-decoration: none;" class=3D""><span style=3D"care=
t-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: n=
ormal; font-variant-caps: normal; font-weight: normal; letter-spacing: norma=
l; text-align: start; text-indent: 0px; text-transform: none; white-space: n=
ormal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: n=
one; float: none; display: inline !important;" class=3D"">much traffic for f=
ixed lines in not so developed parts of the world.</span><br style=3D"caret-=
color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: no=
rmal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal=
; text-align: start; text-indent: 0px; text-transform: none; white-space: no=
rmal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: no=
ne;" class=3D""></div></blockquote><div><br class=3D""></div><div>Yes. It ca=
uses more traffic than BIP37.</div><div>Basic block filters for current last=
~7 days (1008 blocks) are about 19MB (just the filters).</div><div>On top, y=
ou will probably fetch a handful of irrelevant blocks due to the FPs and due=
to true relevant txns.</div><div>A over-the-thumb estimation: ~25MB per wee=
k of catch-up.</div><div>If you where offline for a month: ~108MB</div><div>=
<br class=3D""></div><div>Thats certainly more then BIP37 BF (measured 1.6MB=
total traffic with android schildbach wallet restore blockchain for 8 week [=
7 weeks headers, 1week merkleblocks]).</div><div><br class=3D""></div><div>B=
ut lets look at it like this: for an additional, say 25MB per week (maybe a b=
it more), you get the ability to filter blocks without depending on serving p=
eers who may compromise your financial privacy.</div><div>Also, if you keep t=
he filters, further rescans do consume the same or less bandwidth than BF BI=
P37.</div><div>In other words: you have the chance to potentially increase p=
rivacy by consuming bandwidth in the range of a single audio podcast per wee=
k.</div><div><br class=3D""></div><div>I would say the job of protocol devel=
opers is protect users privacy where it=E2=80=99s possible (as a default).</=
div><div>It=E2=80=99s probably a debatable point wether 25MB per week of tra=
ffic is worth a potential increase in privacy, though I absolutely think 25M=
B/week is an acceptable tradeoff.</div><div>Saving traffic is possible by us=
ing BIP37 or stratum/electrum=E2=80=A6 but developers should make sure users=
are __warned about the consequences__!</div><div><br class=3D""></div><div>=
Additionally, it looks like, peer operators are not endless being willing to=
serve =E2=80=93 for free =E2=80=93 a CPU/disk intense service with no benef=
its for the network. I would question wether a decentralised form of BIP37 i=
s sustainable in the long run (if SPV wallet provider bootstrap a net range o=
f NODE_BLOOM peers to make it more reliable on the network would be snake-oi=
l).</div><div><br class=3D""></div><br class=3D""><blockquote type=3D"cite" c=
lass=3D""><div class=3D""><br style=3D"caret-color: rgb(0, 0, 0); font-famil=
y: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal=
; font-weight: normal; letter-spacing: normal; text-align: start; text-inden=
t: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webki=
t-text-stroke-width: 0px; text-decoration: none;" class=3D""><span style=3D"=
caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-sty=
le: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: n=
ormal; text-align: start; text-indent: 0px; text-transform: none; white-spac=
e: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoratio=
n: none; float: none; display: inline !important;" class=3D"">2) It filters b=
locks only. It doesn't address unconfirmed transactions.</span><br style=3D"=
caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-sty=
le: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: n=
ormal; text-align: start; text-indent: 0px; text-transform: none; white-spac=
e: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoratio=
n: none;" class=3D""></div></blockquote><div><br class=3D""></div>Well, unco=
nfirmed transaction are uncertain for various reasons.</div><div><br class=3D=
""></div><div>BIP158 won't allow you to filter the mempool.</div><div>But as=
soon as you are connected to the network, you may fetch tx with inv/getdata=
and pick out the relevant ones (causes also traffic).</div><div>Unclear and=
probably impossible with the current BIP158 specs to fetch transactions tha=
t are not in active relay and are not in a block (mempool txns, at least thi=
s is true with the current observed relay tactics).</div><div><div><br class=
=3D""></div><br class=3D""><blockquote type=3D"cite" class=3D""><div class=3D=
""><span style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-si=
ze: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal=
; letter-spacing: normal; text-align: start; text-indent: 0px; text-transfor=
m: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0=
px; text-decoration: none; float: none; display: inline !important;" class=3D=
"">3) Afaik, it enforces/encourages address re-use. This stems from the</spa=
n><br style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size:=
12px; font-style: normal; font-variant-caps: normal; font-weight: normal; l=
etter-spacing: normal; text-align: start; text-indent: 0px; text-transform: n=
one; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;=
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, 0)=
; font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-=
caps: normal; font-weight: normal; letter-spacing: normal; text-align: start=
; text-indent: 0px; text-transform: none; white-space: normal; word-spacing:=
0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; di=
splay: inline !important;" class=3D"">fact that the server decides on the fi=
lter and in particular on the</span><br style=3D"caret-color: rgb(0, 0, 0); f=
ont-family: Helvetica; font-size: 12px; font-style: normal; font-variant-cap=
s: normal; font-weight: normal; letter-spacing: normal; text-align: start; t=
ext-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0p=
x; -webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><span s=
tyle=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; f=
ont-style: normal; font-variant-caps: normal; font-weight: normal; letter-sp=
acing: normal; text-align: start; text-indent: 0px; text-transform: none; wh=
ite-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-d=
ecoration: none; float: none; display: inline !important;" class=3D"">false p=
ositive rate. On wallets with many addresses, a hardcoded filter</span><br s=
tyle=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; f=
ont-style: normal; font-variant-caps: normal; font-weight: normal; letter-sp=
acing: normal; text-align: start; text-indent: 0px; text-transform: none; wh=
ite-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-d=
ecoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, 0); font-=
family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: n=
ormal; font-weight: normal; letter-spacing: normal; text-align: start; text-=
indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -=
webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: i=
nline !important;" class=3D"">will be too blurry and thus each block will be=
matched. So wallets that</span><br style=3D"caret-color: rgb(0, 0, 0); font=
-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: n=
ormal; font-weight: normal; letter-spacing: normal; text-align: start; text-=
indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -=
webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><span styl=
e=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; fon=
t-style: normal; font-variant-caps: normal; font-weight: normal; letter-spac=
ing: normal; text-align: start; text-indent: 0px; text-transform: none; whit=
e-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-dec=
oration: none; float: none; display: inline !important;" class=3D"">follow t=
he "one address per incoming payment" pattern (e.g. HD wallets)</span><br st=
yle=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; f=
ont-style: normal; font-variant-caps: normal; font-weight: normal; letter-sp=
acing: normal; text-align: start; text-indent: 0px; text-transform: none; wh=
ite-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-d=
ecoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, 0); font-=
family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: n=
ormal; font-weight: normal; letter-spacing: normal; text-align: start; text-=
indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -=
webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: i=
nline !important;" class=3D"">at some point will be forced to wrap their key=
chains back to the</span><br style=3D"caret-color: rgb(0, 0, 0); font-famil=
y: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal=
; font-weight: normal; letter-spacing: normal; text-align: start; text-inden=
t: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webki=
t-text-stroke-width: 0px; text-decoration: none;" class=3D""><span style=3D"=
caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-sty=
le: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: n=
ormal; text-align: start; text-indent: 0px; text-transform: none; white-spac=
e: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoratio=
n: none; float: none; display: inline !important;" class=3D"">beginning. If I=
'm wrong on this one please let me know.</span><br style=3D"caret-color: rgb=
(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font=
-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-ali=
gn: start; text-indent: 0px; text-transform: none; white-space: normal; word=
-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=
=3D""></div></blockquote><div><br class=3D""></div><div>I=E2=80=99m probably=
the wrong guy to ask (haven=E2=80=99t made the numbers) but last time I res=
canned a Core wallet (in my dev branch) with block filters (and a Core walle=
t has >2000 addresses by default) it fetched a low and acceptable amount o=
f false positive blocks.</div><div>(Maybe someone who made the numbers step i=
n here.)</div><div><br class=3D""></div><div>Though, large wallets =E2=80=93=
AFAIK =E2=80=93 also operate badly with BIP37.</div><br class=3D""><blockqu=
ote type=3D"cite" class=3D""><div class=3D""><br style=3D"caret-color: rgb(0=
, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-v=
ariant-caps: normal; font-weight: normal; letter-spacing: normal; text-align=
: start; text-indent: 0px; text-transform: none; white-space: normal; word-s=
pacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=3D=
""><span style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-si=
ze: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal=
; letter-spacing: normal; text-align: start; text-indent: 0px; text-transfor=
m: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0=
px; text-decoration: none; float: none; display: inline !important;" class=3D=
"">4) The filters are not yet committed to the blockchain. Until that</span>=
<br style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 1=
2px; font-style: normal; font-variant-caps: normal; font-weight: normal; let=
ter-spacing: normal; text-align: start; text-indent: 0px; text-transform: no=
ne; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; t=
ext-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, 0); f=
ont-family: Helvetica; font-size: 12px; font-style: normal; font-variant-cap=
s: normal; font-weight: normal; letter-spacing: normal; text-align: start; t=
ext-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0p=
x; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; displ=
ay: inline !important;" class=3D"">happens we'd have to trust a server to pr=
ovide correct filters.</span><br style=3D"caret-color: rgb(0, 0, 0); font-fa=
mily: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: nor=
mal; font-weight: normal; letter-spacing: normal; text-align: start; text-in=
dent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -we=
bkit-text-stroke-width: 0px; text-decoration: none;" class=3D""></div></bloc=
kquote><br class=3D""></div><div>I wouldn=E2=80=99t say so. It=E2=80=99s on a=
similar level than BIP37.</div><div>BIP37 is not =E2=80=93 and can not =E2=80=
=93 be committed to the blockchain.</div><div>You fully trust the peer that i=
t won=E2=80=99t=E2=80=A6</div><div>a) create fake unconfirmed transactions (=
would be the same if a BIP158 wallet would show you unconfirmed transaction)=
</div><div>b) lies by omission (you will miss relevant transactions, eventua=
lly swipe your wallet and loose coins)</div><div><br class=3D""></div><div>I=
MO, the point b) is true for BIP37 and BIP158 (as long as not commited).</di=
v><div>In both cases, you can reduce the trust by comparing between peers / f=
ilter-providers.</div><div><br class=3D""></div><div>b) is conceptually solv=
able with a soft-fork (commitment) in BIP158 (not with BIP37).</div><div><br=
class=3D""></div><div>Additionally, block-filters will, very likely, be use=
ful for other features (load/rescan an [old] wallet on a prune peer that has=
the filters constructed).</div><div><br class=3D""></div><div><br class=3D"=
"></div><div><br class=3D""></div><div>There is probably no clear answer lik=
e =E2=80=9EX is better than Y=E2=80=9C.</div><div><br class=3D""></div><div>=
Personally I would like to see developers being more honest/transparent to u=
sers about the implications of the used filtering,... and giving them choice=
s.</div><div>Imagine a user can choose between =E2=80=9EElectrum / BIP37 / B=
IP158=E2=80=9C depending on his needs for privacy and availability of bandwi=
dth. Eventually also taking the future usage of this wallet (will he load ol=
d private keys, will he receive money daily, etc.) into account.</div><div><=
br class=3D""></div><div>Plus, full node hardware appliances that run at hom=
e (or in a trusted environment) are solving many of these issues plus adding=
a bunch of great features =E2=80=93 if done right.</div><div><br class=3D""=
></div><div>/jonas</div></div></blockquote><blockquote type=3D"cite"><div di=
r=3D"ltr"><span>_______________________________________________</span><br><s=
pan>bitcoin-dev mailing list</span><br><span><a href=3D"mailto:bitcoin-dev@l=
ists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a></span><b=
r><span><a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoi=
n-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a></s=
pan><br></div></blockquote></body></html>=
--Apple-Mail-FE382715-0483-4F15-993C-AB8315ADCD40--
|