public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Andreas Schildbach <andreas@schildbach.de>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Bitcoin Core to disable Bloom-based Filtering by default
Date: Tue, 23 Jul 2019 16:47:18 +0200	[thread overview]
Message-ID: <qh76ln$41ag$1@blaine.gmane.org> (raw)
In-Reply-To: <qh2qj1$7sg4$1@blaine.gmane.org>

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



  parent reply	other threads:[~2019-07-23 14:47 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-20 17:46 [bitcoin-dev] Bitcoin Core to disable Bloom-based Filtering by default 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
2019-07-22 17:17     ` Luke Dashjr
2019-07-22 17:26   ` Luke Dashjr
2019-07-23 14:47   ` Andreas Schildbach [this message]
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='qh76ln$41ag$1@blaine.gmane.org' \
    --to=andreas@schildbach.de \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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