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
|
Return-Path: <dev@jonasschnelli.ch>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 270D9CA9
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 May 2018 07:47:48 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from bitcoin.jonasschnelli.ch (bitcoinsrv.jonasschnelli.ch
[138.201.55.219])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 0F3606CF
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 May 2018 07:47:46 +0000 (UTC)
Received: by bitcoin.jonasschnelli.ch (Postfix, from userid 1002)
id D915515E4C9F; Thu, 17 May 2018 09:47:45 +0200 (CEST)
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Spam-Level:
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
version=3.3.1
Received: from [192.168.0.8] (cable-static-238-67.teleport.ch [213.188.238.67])
by bitcoin.jonasschnelli.ch (Postfix) with ESMTPSA id 44C9A15E1B3C;
Thu, 17 May 2018 09:47:44 +0200 (CEST)
From: Jonas Schnelli <dev@jonasschnelli.ch>
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Content-Type: multipart/signed;
boundary="Apple-Mail=_B3ACF84B-CD94-4B3D-A9A1-6EA796FB9001";
protocol="application/pgp-signature"; micalg=pgp-sha256
X-Priority: 3
Date: Thu, 17 May 2018 09:47:34 +0200
References: <trinity-7531fbc9-dd91-4b67-a415-605d261d7851-1526505767645@3c-app-mailcom-bs10>
To: Caius Cosades <cosades@gmx.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <trinity-7531fbc9-dd91-4b67-a415-605d261d7851-1526505767645@3c-app-mailcom-bs10>
Message-Id: <A4D8581D-7846-4218-BAB4-5973A1A7CD2D@jonasschnelli.ch>
X-Mailer: Apple Mail (2.3445.6.18)
X-Virus-Scanned: clamav-milter 0.99.4 at bitcoinsrv.jonasschnelli.ch
X-Virus-Status: Clean
Subject: Re: [bitcoin-dev] Moving away from BIP37, unsetting NODE_BLOOM
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: Thu, 17 May 2018 07:47:48 -0000
--Apple-Mail=_B3ACF84B-CD94-4B3D-A9A1-6EA796FB9001
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
Hi Caius
Thanks for brining this up.
As far as it looks, one of the major SPV library does not yet respect =
the NODE_BLOOM service flag [1]. Unsure sure about others.
It think disabling NODE_BLOOM services by default in full node =
implementations makes sense as soon as BIP158 [2] (compact block =
filters) has been implemented and therefore NODE_COMPACT_FILTERS is =
signalled broadly. Unsure if it would make sense to even wait for block =
filter commitment softfork (probably no).
Then, the question is, if there are alternatives for mempool filtering =
(display unconfirmed transactions) or if the protocol recommendation are =
to disable that by default or recommend to use centralised filtering =
technique via wallet provider infrastructure (privacy?!).
I guess everyone here agrees that there are major privacy and =
load-distribution issues with BIP37, and, that it should be disabled in =
the long run.
But, due to the lack of alternatives, there is the risk of breaking =
existing SPV client models and thus pushing users to complete =
centralised validation-solutions (and even towards centralised =
key-storage), which, may result in making privacy and security even more =
worse.
I personally miss a long term concept how to keep non expert users (or =
say light clients) close to the p2p protocol in a decentralized fashion. =
Unclear how decentralized fee estimations and =E2=80=9Eincoming =
transactions=E2=80=9C (which is something users want even if it's a =
broken concept) are handled in the future.
=E2=80=94
/jonas
[1] https://github.com/bitcoinj/bitcoinj/pull/1212
[2] https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki
> Am 16.05.2018 um 23:22 schrieb Caius Cosades via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org>:
>=20
> As previously discussed[0][1][2] on the mailing list, github issue =
commentary, and IRC channels, there's substantial reason to disable =
BIP37 in network nodes which are getting stronger as the size of the =
chain increases. BIP37 has significant denial of service issues which =
are unsolvable in the design, it introduces undue load on the bitcoin =
network by default, and doesn't provide an acceptable amount of =
security and reliability to "lightweight wallets" as originally =
intended.
>=20
> BIP37 allows "lightweight wallets" to connect to nodes in the network, =
and request that they load, deseralize, and expensively apply an =
arbitrary bloom filter to their block files and mempool. This should =
never have been the role of nodes in the network, rather it should have =
been opt-in, or performed by a different piece of software entirely. The =
inability of the nodes to cache the responses or meaningfully rate limit =
them makes it detrimental to serve these requests.
>=20
> BIP37 was intended to have stronger privacy than it does in =
reality[3][4], where effectively any node that can capture `filterload` =
and `filteradd` responses can trivially de-anonymize an entire wallet =
that has connected irrespective of the amount of noise they add to their =
filters. The connected node lying by omission is undetectable by any =
wallet software, where they will be lead to believe that there are no =
matching responses; this is counter-able by further destroying privacy =
and loading down the network by having multiple peers simultaneously =
return filter results and hoping that at least one isn't lying.
>=20
> NODE_BLOOM has been implemented already which allows nodes to signal =
in their service message that they do, or do not support filtering. I =
suggest that in the next major release this is defaulted to 0, and any =
software relying on BIP37 move to using other filtering options, or =
another piece of dedicated software to serve the requests. Future =
releases of the reference software should remove BIP37 commands =
entirely.
>=20
>=20
> [0]: =
https://www.reddit.com/r/Bitcoin/comments/3hjak7/the_hard_work_of_core_dev=
s_not_xt_makes_bitcoin/cu9xntf/?context=3D3
> [1]: https://github.com/bitcoin/bitcoin/issues/6578
> [2]: =
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010535=
.html
> [3]: https://jonasnick.github.io/slides/2016-zurich-meetup.pdf
> [4]: https://eprint.iacr.org/2014/763.pdf
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--Apple-Mail=_B3ACF84B-CD94-4B3D-A9A1-6EA796FB9001
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEyhopCNzi8TB0xizeHrd2uwPHki0FAlr9M5YACgkQHrd2uwPH
ki02mw/7BQlDmgxdzkVIYXCoF1twgt55e6OrDynxeyYaJome/U/6zA9LQVzTs8e8
Z1GDXymV2UNYcH8hLQHeXIH4dkkav+rZTszPtW3iu1JoOoFPb8/RBQhcd6OPHjSk
nzgqoT86DjZ12AnGWyA7m8QN/6pnr9TPHBuCpcMcPA0l4lSBlpfb46ab17yZRZIw
rvS9EYZymCGx4ioNdyqbvKlLXR+kK21mX547Y+L+tJjSJic/soXaqMU49zngHOyz
3EuQI/aZprdD5AZfsdcyGAcE6i9QLpsSml6n8sLKQAZmi7KKxgiqh9QSA2A0wFBU
mw6TTDZCL4cT9RG5VbjfIkZ1Gh7B38J5jAMg7F/S79K+v0U3d6BkBq8+mEfsL/2H
0FYpVDF0DZTyu+1+hppmnXV/UacsKPVXSEPpq2OtZ1ADa0yKxivFLkJUhBcUvaat
no4zhb6lQ3DApWaJGEOI+XvHNMpdsqw7xe3jOjeim7WNn358FJcORetNSH6+kch0
nd3rNydyZP3xdHMOTirkOhMMiQGQkJ0q8HlE4Ty6ihnIItH6ALIOyHlxFwqVt1uZ
0gRQG/kpIsG8hISpNzuGlf3VgFO6WlIpWAMR2l4JdzFmHq7QJU+UadOtxwICBesy
cM0mgvve+Kn78DCiYsyFsw/Ubl4c+satl62RM3BGrxpDqyYsEuo=
=lvQU
-----END PGP SIGNATURE-----
--Apple-Mail=_B3ACF84B-CD94-4B3D-A9A1-6EA796FB9001--
|
