Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 022F3AE0 for ; Mon, 22 Jul 2019 13:25:40 +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 CC2A77C3 for ; Mon, 22 Jul 2019 13:25:30 +0000 (UTC) Received: from [192.168.0.199] (cable-static-140-182.teleport.ch [87.102.140.182]) by bitcoin.jonasschnelli.ch (Postfix) with ESMTPSA id 62B8F15E61A6; Mon, 22 Jul 2019 15:25:29 +0200 (CEST) From: Jonas Schnelli Content-Type: multipart/signed; boundary="Apple-Mail=_62F99736-21ED-4C41-AAA3-B7CD729ACA60"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 22 Jul 2019 15:25:25 +0200 References: <59fad2b6-9b15-ffec-116e-91d27ce29f80@mattcorallo.com> To: Andreas Schildbach , Bitcoin Protocol Discussion In-Reply-To: Message-Id: <122FF05A-8A80-4C13-95D1-BA67B602246A@jonasschnelli.ch> X-Mailer: Apple Mail (2.3445.104.11) X-Virus-Scanned: clamav-milter 0.100.3 at bitcoinsrv.jonasschnelli.ch X-Virus-Status: Clean 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: Mon, 22 Jul 2019 15:05:51 +0000 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 13:25:40 -0000 --Apple-Mail=_62F99736-21ED-4C41-AAA3-B7CD729ACA60 Content-Type: multipart/alternative; boundary="Apple-Mail=_B7316311-C08B-4766-ACC0-5AF813B57A35" --Apple-Mail=_B7316311-C08B-4766-ACC0-5AF813B57A35 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Andreas >> well-known DoS vectors >=20 > I asked many people, even some "core developers" at meetings, but = nobody > ever was able to explain the DoS vector. I think this is just a myth. No. They are not a myth [1] [2] [3]. > Yes, you can set an overly blurry filter and thus cause useless = traffic, > but it never exceeds just drinking from the full firehose (which this > change doesn't prohibit). So where is the point? An attacker will just > switch filtering off, or in fact has never used it. I guess it=E2=80=99s not about traffic DoS. It=E2=80=99s about asking a = peer for extensive CPU and disk work. The NODE_BLOOM peers do provide = this service for free while it=E2=80=99s not directly beneficial for the = Bitcoin Network (pure consumed CPU/disk time). >=20 >> It is not anticipated that >> this will result in a significant lack of availability of >> NODE_BLOOM-enabled nodes in the coming years >=20 > Why don't you anticipate that? People almost never change defaults, > especially if it's not for their own immediate benefit. At the same > time, release notes in general recommend updating to the latest = version. > I *do* anticipate this will reduce the number of nodes usable by a = large > enough amount so that the feature will become unstable. I guess this is speculation. A quick lookup in my crawler databases shows me that there are more than = 8=E2=80=99000 =E2=80=9Egood=E2=80=9C peers supporting NODE_BLOOM right = now. I don=E2=80=99t expect that this number drops rapidly, but maybe in the = long run ("in years=E2=80=9C, but again: speculation). We eventually can=E2=80=99t expect - in the long run - that nodes = provide disk/CPU intense services for free to clients not contributing = back to the network. However, sadly, due to the privacy leaks in BIP37, I expect that there = will always be a wide range of peers offering NODE_BLOOM in return of = collecting valuable data. >=20 >> clients >> which rely on the availability of NODE_BLOOM-supporting nodes on the >> P2P network should consider the process of migrating >> to a more modern (and less trustful and privacy-violating) = alternative >> over the coming years. >=20 > There is no such alternative. >=20 > I strongly recommend postponing this change until an alternative = exists > and then give developers enough time to implement, test and roll out. NODE_BLOOM was added in Core 0.12 [4]. BIP111 is from 2015 [2]. One who follows the protocol development should have known that = defaulting NODE_BLOOM to off was something anticipated by most = developers. I would say that there are possible alternatives, like BIP158 (though = BIP157 is not widely available on the network yet). Client side filtering works also by collecting the filter form a = centralised service by the wallet provider(s) or a CDN. You may miss transactions by a dishonest filter-packet, so may you by = talking to a dishonest NODE_BLOOM peer. Of course BIP158 is still young and =E2=80=93 who knows =E2=80=93 = eventually once committed to consensus layer (coinbase). > I also think as long as we don't have an alternative, we should = improve > the current filtering for segwit. E.g. testing the scripts themselves > and each scriptPubKey spent by any input against the filter would do, > and it also fixes the main privacy issue with server-side filtering > (wallets have to add two items per address to the filter). I think the consensus among protocol developers is (please speak up), = that BIP37 (public server based tx filtering) =E2=80=93 in general =E2=80=93= was a conceptual mistake. Maybe extending it further is the wrong step, especially when promising = alternatives like BIP158 (neutrino) are around. The fact that nobody cared about extending it for SW may also underline = that BIP37 is seen as a conceptual mistake and/or "low interest in = further extensions=E2=80=9C. /jonas [1] https://github.com/petertodd/bloom-io-attack = [2] https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki = [3] https://github.com/bitcoin/bitcoin/pull/9238 = [4] = https://github.com/bitcoin/bitcoin/blob/47d981e8273804a040d71665a4cb16038d= 6717e1/doc/release-notes/release-notes-0.12.0.md#node_bloom-service-bit --Apple-Mail=_B7316311-C08B-4766-ACC0-5AF813B57A35 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Andreas

well-known DoS vectors

I asked many people, even some = "core developers" at meetings, but nobody
ever was able to = explain the DoS vector. I think this is just a myth.

No. = They are not a myth [1] [2] [3].

Yes, you can set an overly blurry filter and thus cause = useless traffic,
but it never exceeds just drinking from = the full firehose (which this
change doesn't prohibit). So = where is the point? An attacker will just
switch filtering = off, or in fact has never used it.

I = guess it=E2=80=99s not about traffic DoS. It=E2=80=99s about asking a = peer for extensive CPU and disk work. The NODE_BLOOM peers do provide = this service for free while it=E2=80=99s not directly beneficial for the = Bitcoin Network (pure consumed CPU/disk time).


It is not = anticipated that
this will result in a significant lack of = availability of
NODE_BLOOM-enabled nodes in the coming = years

Why don't you anticipate = that? People almost never change defaults,
especially if = it's not for their own immediate benefit. At the same
time, = release notes in general recommend updating to the latest version.
I *do* anticipate this will reduce the number of nodes usable = by a large
enough amount so that the feature will become = unstable.

I guess this is speculation.
A quick = lookup in my crawler databases shows me that there are more than 8=E2=80=99= 000 =E2=80=9Egood=E2=80=9C peers supporting NODE_BLOOM right = now.
I don=E2=80=99t expect that this number drops rapidly, = but maybe in the long run ("in years=E2=80=9C, but again: = speculation).

We eventually = can=E2=80=99t expect - in the long run - that nodes provide disk/CPU = intense services for free to clients not contributing back to the = network.
However, sadly, due to the privacy leaks in BIP37, I = expect that there will always be a wide range of peers offering = NODE_BLOOM in return of collecting valuable data.


clientswhich rely on the availability of NODE_BLOOM-supporting = nodes on the
P2P network should consider the process of = migrating
to a more modern (and less trustful and = privacy-violating) alternative
over the coming years.

There is no such alternative.

I strongly recommend postponing this change = until an alternative exists
and then give developers = enough time to implement, test and roll out.

NODE_BLOOM was added in Core 0.12 = [4].
BIP111 is from 2015 [2].
One who follows the = protocol development should have known that defaulting NODE_BLOOM to off = was something anticipated by most developers.

I would say that there are possible alternatives, = like BIP158 (though BIP157 is not widely available on the network = yet).
Client side filtering works also by collecting the = filter form a centralised service by the wallet provider(s) or a = CDN.
You may miss transactions by a dishonest filter-packet, = so may you by talking to a dishonest NODE_BLOOM peer.
Of = course BIP158 is still young and =E2=80=93 who knows =E2=80=93 = eventually once committed to consensus layer (coinbase).


I also think as long as we = don't have an alternative, we should improve
the current = filtering for segwit. E.g. testing the scripts themselves
and each scriptPubKey spent by any input against the filter = would do,
and it also fixes the main privacy issue with = server-side filtering
(wallets have to add two items per = address to the filter).

I think the consensus among protocol developers is = (please speak up), that BIP37 (public server based tx filtering) =E2=80=93= in general =E2=80=93 was a conceptual mistake.
Maybe = extending it further is the wrong step, especially when promising = alternatives like BIP158 (neutrino) are around.
The fact that = nobody cared about extending it for SW may also underline that BIP37 is = seen as a conceptual mistake and/or "low interest in further = extensions=E2=80=9C.


/jonas


= --Apple-Mail=_B7316311-C08B-4766-ACC0-5AF813B57A35-- --Apple-Mail=_62F99736-21ED-4C41-AAA3-B7CD729ACA60 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----- iQIzBAEBCAAdFiEEyhopCNzi8TB0xizeHrd2uwPHki0FAl01uUUACgkQHrd2uwPH ki1M2Q//Sc3cYCeBvMlLom8Ys0aGL4OjSjlwgCHOyfYD8erWiPWSdGPN4dIci+Ud E4TuwPgJlJYxR418NvEmt9Zpj5xAQIMoGnoFTnU9SXktXK6IrDWb2SBDRHEPY74h uK06wQ82O+360FQ+XXBFiSkvuKkS1FGHOnPSqgsBV6SydY3GxD6YRPkvRsp7xL6k Z2IyalLjENUr9FG9GVxwPig7XmJ/jY/ANyG5aeVvrXtrAqXf8yku81tc6aoMqiNk 9NpQwlGFZIaA1iwESRU84pZwwjk3bVFuTYDoO3w9SDgm1WtQsZZUucqW1oHwuiHA Kr7cpQWDj6uperxW8upnz5gaeAjkxIQ4TWsO1UzyTICZDji2k0vrZMELKnOD2NbV 3OrMVQSw53JVh+RIKIh31eUIpnF4Vb7phEH1sfHEz2St4/vqWRrHWm8wL2EEO7sQ q5lo9vD3/wpdtuieAHL2a/FIxvhji3Sp/yoyyd7cVpEXhYfEncNo3hgzoSIGGJQC 7wi8zgiqWXQ7lhwNLmBvTSCvlE/KXQHlyfQLbBBwhtrTTBh7330tNXgJdV9G8wpq n9uoHZm9M/LEGKxbjhctireMIuSyrCQ5YmhMy7l6+2qEr7ODpBA4b1st+9Jh1np3 WZUHlhJ4Ab/tzUGaNsfmeeNkg8dLC/uLxZk3ZmskKqrkF/d2MAk= =lhN1 -----END PGP SIGNATURE----- --Apple-Mail=_62F99736-21ED-4C41-AAA3-B7CD729ACA60--