public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd.org>
To: Alan Reiner <etotheipi@gmail.com>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Bloom bait
Date: Sun, 8 Jun 2014 17:45:29 -0400	[thread overview]
Message-ID: <20140608214529.GB4191@savin> (raw)
In-Reply-To: <53936B87.3060804@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2347 bytes --]

On Sat, Jun 07, 2014 at 03:44:07PM -0400, Alan Reiner wrote:
> 
> On 06/07/2014 07:22 AM, Mike Hearn wrote:
> >
> > You can send different bloom filters to different peers too, so I'm
> > not sure why you're listing subsetting as a unique advantage of prefix
> > filters.
> >
> >
> 
> Please let me know if we've gone down this path before, but it would
> seem that the more different bloom filters you create, the more
> information you give away.  It would be most useful to create a single
> bloom filter that captures every address you ever intend to use (say a
> look ahead of 1000 addresses), and then only ever communicate that. 
> Once people see multiple filters that you produce, they can start
> looking at the intersection of them to reduce the identity space.  I
> would expect that after enough bloom variants, they could figure out a
> perfect subset of blockchain addresses in your wallet.  (I suppose you
> could intentionally select an extra 20% addresses to include in every
> bloom filter, but it's a hack).
> 
> Similarly, if you keep updating your bloom filter to include more
> addresses, the difference in what passes through the previous one and
> the new one gives away information about new addresses you created.

You're completely correct. You can use the same nTweak value for each
filter and then slice up the filters bitwise, but then you end up
linking every query you make to your identity unless you just used a
fixed nTweak that everyone else uses.  (e.g. zero) If you do that, you
still have the problem that you're greatly increasing the load on the
network.

In any case, all this shows is that in the future bloom filters will
very likely go away eventually, and to make that upgrade path smooth it
only makes sense to define a way for nodes to let others know whether or
not bloom is supported. A NODE_BLOOM service bit is a very reasonable
and simple way to do exactly that, and is defacto what implementations
that don't support bloom filters do anyway.

Note BTW that re: DNS seeds, once the NODE_BLOOM BIP is accepted and the
NODE_BLOOM patch merged into bitcoind, I'll write a patch for sipa's
seeder to make it only return seeds with bloom filter support.

-- 
'peter'[:-1]@petertodd.org
00000000000000003afb1fdf0867fc063775e69f9ae79870bb8727f25b49e88f

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

  reply	other threads:[~2014-06-08 21:44 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-06  8:19 [Bitcoin-development] NODE_BLOOM service bit Peter Todd
2014-06-06  8:48 ` Adam Back
2014-06-06  9:03   ` Gregory Maxwell
2014-06-06  9:11     ` Peter Todd
2014-06-06  9:04   ` Peter Todd
2014-06-06 10:45     ` Adam Back
2014-06-06 16:46       ` [Bitcoin-development] Bloom bait Peter Todd
2014-06-06 16:58         ` Gregory Maxwell
2014-06-06 17:05           ` Peter Todd
2014-06-06 17:10             ` Gregory Maxwell
2014-06-06 17:45               ` Peter Todd
2014-06-07 11:22                 ` Mike Hearn
2014-06-07 19:44                   ` Alan Reiner
2014-06-08 21:45                     ` Peter Todd [this message]
2014-06-10 10:41                       ` Mike Hearn
2014-06-08 21:35                   ` Peter Todd
2014-06-10 10:38                     ` Mike Hearn
2014-06-10 13:02                       ` Jeff Garzik
2014-06-10 17:08                       ` Peter Todd
2014-06-11  8:57                         ` Mike Hearn

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=20140608214529.GB4191@savin \
    --to=pete@petertodd.org \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=etotheipi@gmail.com \
    /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