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