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
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>
Subject: Re: [bitcoin-dev] Moving away from BIP37, unsetting NODE_BLOOM
Precedence: list


--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--