Bloom filter is resent on each received coin

[GoogleCodeExporter]

This happens with pay to pubkey and watched scripts.

Original issue reported on code.google.com by c1.devra...@niftybox.net on 15 Dec 2013 at 10:47

[GoogleCodeExporter]

s/bug/enhancement/

Original comment by c1.devra...@niftybox.net on 15 Dec 2013 at 10:47

[GoogleCodeExporter]

This is more of a major bug - it breaks the whole privacy model of bloom 
filters...

Original comment by BlueMatt...@gmail.com on 16 Dec 2013 at 2:50

• Added labels: Type-Defect, Priority-Critical
• Removed labels: Type-Enhancement, Priority-Medium

[GoogleCodeExporter]

To elaborate a bit further, in the current implementation a peer can send you a 
transaction to a pubkey it thinks is yours, and you will immediately respond 
with a yes/no filter update.
The filter update is (usually) entirely unnecessary. To fix this issue 
properly, we should never update filters while downloading as the download peer 
will deal with the updating for us. While downloading, we should not send any 
other peers filters (preventing them from advertising any transactions/blocks). 
After download completes, we should create an updated filter and pass that only 
to the other (non-download) peers. After updating all the filters, we can make 
a mempool request to get all the unconfirmed transactions.

Original comment by BlueMatt...@gmail.com on 21 Dec 2013 at 11:13

[GoogleCodeExporter]

This is made trickier by the fact that the download peer can change during the 
download.

Original comment by hearn@google.com on 23 Dec 2013 at 12:45

• Changed state: Accepted

[GoogleCodeExporter]

Lowering priority. We already have a configuration where filters are very tight 
with virtually no noise, so this is more of a privacy improvement than a 
serious bug fix.

Original comment by hearn@google.com on 23 Dec 2013 at 12:46

• Added labels: Priority-Medium
• Removed labels: Priority-Critical

[GoogleCodeExporter]

No, sadly we actually don't. Currently privacy against a nice that wants to 
actively deanonymize you is zero and against any standard peer is very, very 
poor unless you set the FP rate to something like 5%. This, this bug needs 
resolved for the next version 

Original comment by BlueMatt...@gmail.com on 23 Dec 2013 at 11:06

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Yes, we do. Current releases have a very low FP rate configured in the software 
to the extent that we don't really see false positives at all. I don't think 
this will make it for 0.11 and I won't be holding the release for it. This is 
not a regression - we've never used Bloom filters for privacy, just as a way to 
reduce bandwidth.

Original comment by hearn@google.com on 23 Dec 2013 at 11:09

[GoogleCodeExporter]

Hmm, well OK, as long as at least the docs are changed to note that it is 
difficult to configure the filters to provide any real privacy and still get 
significant bandwidth reduction.

Original comment by BlueMatt...@gmail.com on 23 Dec 2013 at 11:12

[GoogleCodeExporter]

I think we should probably have an article on privacy topics. Right now 
bitcoinj doesn't really focus on that because there have been a billion other 
things to do, but now we're getting to a point where most of the important 
functionality/operational/performance issues have been fixed, we'll be able to 
focus on this more in future.

So far we just used Bloom filtering for bandwidth reduction and not privacy 
(because it's complicated, as these various bugs document). We at least need a 
concept of bandwidth modes first. Jim already tried a high FP rate on 3G and it 
made things nearly unusable. Once we know whether we even *can* have FPs, then 
fixing all these issues and attacks would make sense.

Original comment by hearn@google.com on 23 Dec 2013 at 11:27

[GoogleCodeExporter]

Yea, a privacy article would definitely be good.

Original comment by BlueMatt...@gmail.com on 23 Dec 2013 at 11:30

[GoogleCodeExporter]

This is fixed in master.

Original comment by BlueMatt...@gmail.com on 30 Jan 2014 at 9:02

• Changed state: Fixed