From: Jonas Schnelli <dev@jonasschnelli•ch>
To: Andreas Schildbach <andreas@schildbach•de>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bitcoin Core to disable Bloom-based Filtering by default
Date: Mon, 22 Jul 2019 15:25:25 +0200 [thread overview]
Message-ID: <122FF05A-8A80-4C13-95D1-BA67B602246A@jonasschnelli.ch> (raw)
In-Reply-To: <qh2qj1$7sg4$1@blaine.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 4286 bytes --]
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’s not about traffic DoS. It’s about asking a peer for extensive CPU and disk work. The NODE_BLOOM peers do provide this service for free while it’s 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’000 „good“ peers supporting NODE_BLOOM right now.
I don’t expect that this number drops rapidly, but maybe in the long run ("in years“, but again: speculation).
We eventually can’t 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.
>
>> 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.
>
> 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 – who knows – 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) – in general – 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“.
/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/47d981e8273804a040d71665a4cb16038d6717e1/doc/release-notes/release-notes-0.12.0.md#node_bloom-service-bit
[-- Attachment #1.2: Type: text/html, Size: 6236 bytes --]
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2019-07-22 13:25 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-20 17:46 Matt Corallo
2019-07-21 22:56 ` Andreas Schildbach
2019-07-22 5:01 ` Matt Corallo
2019-07-22 15:58 ` Justus Ranvier
2019-07-26 7:45 ` Tamas Blummer
2019-07-22 8:32 ` Peter Todd
2019-07-22 13:25 ` Jonas Schnelli [this message]
2019-07-22 17:17 ` Luke Dashjr
2019-07-22 17:26 ` Luke Dashjr
2019-07-23 14:47 ` Andreas Schildbach
2019-07-24 13:11 ` Justus Ranvier
2019-07-25 3:04 ` Luke Dashjr
2019-07-26 10:04 ` Jonas Schnelli
2019-07-27 16:10 ` Matt Corallo
2019-07-26 16:48 ` Chris
2019-07-27 19:19 ` Luke Dashjr
2019-07-22 15:04 ` Tom Harding
2019-07-22 15:15 ` Dustin Dettmer
[not found] ` <FF0175BF-1D1F-4AD4-9B13-99D522DBCD83@bridge21.com>
2019-08-14 15:07 ` Matt Corallo
2019-07-22 18:52 Peter
2019-07-22 20:42 ` Greg Sanders
2019-07-22 21:17 ` Luke Dashjr
2019-07-23 20:36 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=122FF05A-8A80-4C13-95D1-BA67B602246A@jonasschnelli.ch \
--to=dev@jonasschnelli$(echo .)ch \
--cc=andreas@schildbach$(echo .)de \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox