add countermeasure -- do not update blockchain data filters

[kristovatlas]

attack II.E is:
Reduce the false positive rate of filters by comparing how the filters received from a single client change over time (7df9676792e7439f391c641a206ed4505d6bdf7b5c43f4c8b1dcecf4776ebc75)

It currently only has one countermeasure, OBPPV3/CM22 (eb0dc1462a3d90740def288f8407a3501032a00d92d8ef1926b60778a6a20d86):
If a filter requires an update, send the new filter to a different peer than the peer which has the old filter

with one criterion, OBPPV3/CR28 (eaa21085ff84067e245a2f48ed6c6b27c23040163a7b87ea1f0ab93b2d715489):
A single query for blockchain data may correspond to multiple addresses in a user's wallet, but a separate connection context is used for each query

I'd like to add another countermeasure:

Do not update probabilistic filters sent to peers to query blockchain data

And list OBPPV3/CR25 (e9d26b9622bbc535f5625505cf2e4924847058b97e055323a332f82ed24bf067) under that:
Blockchain data is obtained from a local copy of the blockchain

The reason for this is that CM22 should have a weighting that reflects its <100% effectiveness against attack II.E, given that the second peer that you send an updated filter to may be colluding with the first peer you sent the old filter to.

[kristovatlas]

@dcousens ok with you?

Edit: See below comment

[kristovatlas]

Attack II.F has a similar problem. It's:
Reduce the false positive rate of filters by comparing the transactions sent by a client with the filter they have sent

with only one countermeasure OBPPV3/CM23 (06c9f3f3cf6304568134f64cb27f622c44a73e40c24fe2730164dfbb700b2e73):
Route outgoing transactions through a different route than through the peer which is providing relevant blockchain data

I've decided it would be simpler to just re-use the existing countermeasure OBPPV3/CM16 (16105562d1445b9b15fbeb2f4baa929447e78c71d358b0c22d2df5de8e62a605):
Obtain relevant blockchain data without making queries to other network participants.

I'm not actually sure what of what practical use it would be to try to create bloom filters that include new transactions but are "not updated" -- probably very little.

[dcousens]

What do you mean by "updated"?

[kristovatlas]

Yeah, this is a ill-defined or non-concept. The idea was that you would somehow create a bloom filters A and B, where B includes the same addresses in A plus some extra ones not in A, but somehow make it difficult to correlate A and B.

Maybe you could monkey around the false positive rates between A and B, but it's not obvious to me how.

[dcousens]

I suppose you could take several different bloom filters, compare their address sets and try and derive a subset of the addresses involved with a lower false positive rate.
But, it'd be based only on [blockchain] data you have, not data you don't have (obviously).

[kristovatlas]

CM16 and CR25 should also be listed under II.G: Link different identities based on a bloom/prefix filter or other query that matches blockchain data associated with multiple identities

[crwatkins]

A countermeasure is discussed in BIP 157 & BIP 158