Since client-side filtering (BIP157/158) isn't really an option for light wallets, I'm thinking about how to improve server-side connection filtering (BIP37 aka "bloom filters").
I propose the following changes to BIP37 (via a new BIP of course): --- * A new matching rule For each tx, each output scriptPubKey is tested against the filter. For each tx except coinbase, each scriptPubKey spent by any input is tested against the filter. If any of those matches, the tx or block is considered matching. I think the old matching rules could be removed at some point. In my opinion, this would fix the privacy issue that wallets have to add two items per address to the filter, which has opened an easy way for an attacker to distinguish false positives from true positives. A wallet would now only add one item per address: the scriptPubKey the address represents. I believe this would also get rid of any need to change the filter immediately upon match via the awkward BLOOM_UPDATE_* mechanism. This is because wallets can pre-generate as many addresses as they want. E.g. bitcoinj pre-generates 133 addresses per chain, it will take a long time to consume those. If they're all consumed, a wallet would disconnect and connect to a different peer. This would also open up using client-side filtering to other uses, because entirely scriptPubKeys are matched rather than just pubKeys or pubKey hashes. * "filterload" can only be used once per connection; removal of "filteradd" and "filterclear" If a filter needs to change, better disconnect and connect to a different peer. If an attacker learns two different filters of the same wallet, s/he could derive addresses by correlating the two filters. * A full node may reject a filter at any time A full node would do this to prevent overload, e.g. in case a filter matches too many items. It would send a BIP61 reject message and disconnect. * Optional: A different filter algorithm Perhaps it is in the interest of Bitcoin Core to maintain just one filter algorithm, not two. If at any point they merge BIP157/158, we could perhaps adopt the algorithm from there (Golomb-Rice). * Related: Connection opportunistic encryption See https://gist.github.com/jonasschnelli/c530ea8421b8d0e80c51486325587c52 --- I think this proposal is a significant improvement to privacy. It would also ultimately make the implementations simpler on both sides, as we drop all the old mechanisms. It would however not fix the issue that full nodes can lie to clients by omission in the case of filtered blocks. Ideas? Comments? -- You received this message because you are subscribed to the Google Groups "bitcoinj" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoinj+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
