path: root/66/772b5cf9643dcbce114eef42248db3c118e929

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 022F3AE0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	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 <dev@jonasschnelli.ch>
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>
	<qh2qj1$7sg4$1@blaine.gmane.org>
To: Andreas Schildbach <andreas@schildbach.de>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <qh2qj1$7sg4$1@blaine.gmane.org>
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 <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: 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 =
<https://github.com/petertodd/bloom-io-attack>
[2] https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki =
<https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki>
[3] https://github.com/bitcoin/bitcoin/pull/9238 =
<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

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" =
class=3D""><div>Hi Andreas</div><div><br class=3D""><blockquote =
type=3D"cite" class=3D""><div class=3D""><div class=3D""><blockquote =
type=3D"cite" class=3D"">well-known DoS vectors<br =
class=3D""></blockquote><br class=3D"">I asked many people, even some =
"core developers" at meetings, but nobody<br class=3D"">ever was able to =
explain the DoS vector. I think this is just a myth.<br =
class=3D""></div></div></blockquote><div><br class=3D""></div><div>No. =
They are not a myth [1] [2] [3].</div><div><br =
class=3D""></div><blockquote type=3D"cite" class=3D""><div class=3D""><div=
 class=3D"">Yes, you can set an overly blurry filter and thus cause =
useless traffic,<br class=3D"">but it never exceeds just drinking from =
the full firehose (which this<br class=3D"">change doesn't prohibit). So =
where is the point? An attacker will just<br class=3D"">switch filtering =
off, or in fact has never used it.<br =
class=3D""></div></div></blockquote><div><br class=3D""></div><div>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).</div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div =
class=3D""><br class=3D""><blockquote type=3D"cite" class=3D"">It is not =
anticipated that<br class=3D"">this will result in a significant lack of =
availability of<br class=3D"">NODE_BLOOM-enabled nodes in the coming =
years<br class=3D""></blockquote><br class=3D"">Why don't you anticipate =
that? People almost never change defaults,<br class=3D"">especially if =
it's not for their own immediate benefit. At the same<br class=3D"">time, =
release notes in general recommend updating to the latest version.<br =
class=3D"">I *do* anticipate this will reduce the number of nodes usable =
by a large<br class=3D"">enough amount so that the feature will become =
unstable.<br class=3D""></div></div></blockquote><div><br =
class=3D""></div><div>I guess this is speculation.</div><div>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.</div><div>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).</div><div><br class=3D""></div><div><div>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.</div><div>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.</div></div><div><br =
class=3D""></div><blockquote type=3D"cite" class=3D""><div class=3D""><div=
 class=3D""><br class=3D""><blockquote type=3D"cite" class=3D"">clients<br=
 class=3D"">which rely on the availability of NODE_BLOOM-supporting =
nodes on the<br class=3D"">P2P network should consider the process of =
migrating<br class=3D"">to a more modern (and less trustful and =
privacy-violating) alternative<br class=3D"">over the coming years.<br =
class=3D""></blockquote><br class=3D"">There is no such alternative.<br =
class=3D""><br class=3D"">I strongly recommend postponing this change =
until an alternative exists<br class=3D"">and then give developers =
enough time to implement, test and roll out.<br =
class=3D""></div></div></blockquote><div><br =
class=3D""></div><div><div>NODE_BLOOM was added in Core 0.12 =
[4].</div><div>BIP111 is from 2015 [2].</div><div>One who follows the =
protocol development should have known that defaulting NODE_BLOOM to off =
was something anticipated by most developers.</div><div><br =
class=3D""></div><div>I would say that there are possible alternatives, =
like BIP158 (though BIP157 is not widely available on the network =
yet).</div><div>Client side filtering works also by collecting the =
filter form a centralised service by the wallet provider(s) or a =
CDN.</div><div>You may miss transactions by a dishonest filter-packet, =
so may you by talking to a dishonest NODE_BLOOM peer.</div><div>Of =
course BIP158 is still young and =E2=80=93 who knows =E2=80=93 =
eventually once committed to consensus layer (coinbase).</div><div><br =
class=3D""></div></div><br class=3D""><blockquote type=3D"cite" =
class=3D""><div class=3D""><div class=3D"">I also think as long as we =
don't have an alternative, we should improve<br class=3D"">the current =
filtering for segwit. E.g. testing the scripts themselves<br =
class=3D"">and each scriptPubKey spent by any input against the filter =
would do,<br class=3D"">and it also fixes the main privacy issue with =
server-side filtering<br class=3D"">(wallets have to add two items per =
address to the filter).<br class=3D""></div></div></blockquote><div><br =
class=3D""></div><div>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.</div><div>Maybe =
extending it further is the wrong step, especially when promising =
alternatives like BIP158 (neutrino) are around.</div><div>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.</div></div><div class=3D""><br class=3D""></div><div =
class=3D""><br class=3D""></div>/jonas<br class=3D""><div class=3D""><br =
class=3D""></div><div class=3D""><div>[1]&nbsp;<a =
href=3D"https://github.com/petertodd/bloom-io-attack" =
class=3D"">https://github.com/petertodd/bloom-io-attack</a></div><div>[2]&=
nbsp;<a =
href=3D"https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki" =
class=3D"">https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki<=
/a></div></div><div>[3]&nbsp;<a =
href=3D"https://github.com/bitcoin/bitcoin/pull/9238" =
class=3D"">https://github.com/bitcoin/bitcoin/pull/9238</a></div><div>[4]&=
nbsp;<a =
href=3D"https://github.com/bitcoin/bitcoin/blob/47d981e8273804a040d71665a4=
cb16038d6717e1/doc/release-notes/release-notes-0.12.0.md#node_bloom-servic=
e-bit" =
class=3D"">https://github.com/bitcoin/bitcoin/blob/47d981e8273804a040d7166=
5a4cb16038d6717e1/doc/release-notes/release-notes-0.12.0.md#node_bloom-ser=
vice-bit</a></div><div><br class=3D""></div></body></html>=

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