Leakage Due to the Network Layer
Clearly, the adversary can try to link different Bloom filters to a single wallet by identifying the IP addresses used to outsource the Bloom filters. If, for example, the same IP address outsources two different Bloom filters to a regular node, then that node could directly infer that those filters belong to the same entity.
This leakage is even more exacerbated since an adversary who is connected to an SPV client can see the transactions issued by the client and could potentially use this in order to learn the clients’ addresses.
Information leakage that originates from the network layer can be countered, for example, by SPV clients using anonymizing networks such as Tor  whenever they issue Bitcoin transactions or they outsource their Bloom filters.
Leakage Due to the Insertion of Both Public Keys and Addresses in the Bloom filter
In current implementations of SPV clients, both the addresses and their public keys are inserted in the outsourced Bloom filter. As such, if the adversary knows both the address and its public key, then she he or can trivially test whether an address is a true positive of the filter by checking whether both the address and its public key are inserted within the filter. If not, then it is highly likely that the address is a false positive of the filter.
We believe that the inclusion of both the address and its public key in the Bloom filter is a severe flaw in the current SPV client implementations.
More than 99% of all Bitcoin transactions consist of payments to Bitcoin addresses (or the public key hash); moreover, only 4,587 out of 33 million studied addresses in the system received transactions destined for both their public keys and their public key hashes. This means that for the vast majority of Bitcoin clients, there is no need to include both the public keys and their hashes (i.e., the Bitcoin addresses) in the Bloom filters; inserting one or the other would suffice (in more than 99% of the cases). Note that only inserting the addresses in the Bloom filter would suffice since regular nodes can easily hash the public keys and check whether they match the Bloom filter. However, this clearly incurs additional computational overhead on regular Bitcoin nodes.
-  These numbers were obtained by parsing the Bitcoin blockchain until block # 296000.