Re: [bitcoin-dev] Bitcoin Core to disable Bloom-based Filtering by default

[Andreas Schildbach <andreas@schildbach.de>]

(Rather than replying individually, I try to address questions and add
my remarks in one post.)

> Finally, regarding alternatives, the filter-generation code for
> BIP 157/158 has been in Bitcoin Core for some time, though the
> P2P serving side of things appears to have lost any champions
> working on it.

BIP 157/158 is not an alternative to BIP 37:

1) It causes way too much traffic for mobile users, and likely even too
much traffic for fixed lines in not so developed parts of the world.

2) It filters blocks only. It doesn't address unconfirmed transactions.

3) Afaik, it enforces/encourages address re-use. This stems from the
fact that the server decides on the filter and in particular on the
false positive rate. On wallets with many addresses, a hardcoded filter
will be too blurry and thus each block will be matched. So wallets that
follow the "one address per incoming payment" pattern (e.g. HD wallets)
at some point will be forced to wrap their key chains back to the
beginning. If I'm wrong on this one please let me know.

4) The filters are not yet committed to the blockchain. Until that
happens we'd have to trust a server to provide correct filters.

> Can you specify exactly which wallets those are?

Bitcoin Wallet, Breadwallet, BISQ and many smaller ones.

> the DNS seed infrastructure among others can easily direct
> wallets to those nodes

Last I checked none of the seeds did. But I agree this would be nice to
have.

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

I'm disappointed to learn that supporting 10M wallets gets discredited
down to "no contribution". Each node of course supports just a number of
them, but still...

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

I suspect this is a fallacy. BIP37 doesn't need to be extended for
SegWit. See Bitcoin Wallet and Breadwallet, both support SegWit and use
the original BIP 37.

It's true however that BIP 37 could be made simpler to work with, more
future-proof and more private by simply matching output scripts.

> [1] https://github.com/petertodd/bloom-io-attack

This claims to be a proof of concept, but it's missing the concept. I
could not find a description of the attack and why is it likely to be
exploited (and why it hasn't been exploited yet).

> CPU DoS attacks are also possible

If such an attack exists, it should be easy to defend against. Filter is
using too much CPU time → disconnect and blacklist the IP for some time.
I vaguely remember the infrastructure for misbehaving peers is already
present in bitcoind.


As a side note, Coinbase just announced their 30M'th wallet. I'm
convinced this massive run into custodial wallets is caused by the
public realizing around Dec 2017 that Bitcoin fails to scale. IMHO, BIP
37 is the only scaling technology that has proven successful and could –
if supported and improved rather than choked – continue to help holding
against the bitbanks trend.