1. Lack of support for unconfirmed tx. This alone degrades usage to an optional "more privacy, but much slower" setting. I doubt that the typical light wallet user cares much about privacy, but I can assert users _extremely_ care about speed.
2. It doesn't scale, at least not unless multiple filters are computed by the full nodes, each targetted at a different number of items to be matched. The nodes cannot know how many items the client will put into the filter so at some point the FP rate will become too high for any fixed filter. Of course wallets could revert to re-using addresses; this would work around the problem. 3. Currently there is no block chain commitment of any filter. Even if there is, we can only use client-side filtering for wallets created after that point. Yes, I'd like to post to bitcoin-dev. I will offer to implement the bitcoinj side. However someone will need to do the Bitcoin Core impl. and the politics )-: On 24/04/2019 17.29, Oscar Guindzberg wrote: > It's great to see progress in this area. > > Why client-side filtering is not an option for light wallets? Because > of lack of support for unconfirmed tx? Any other problem on top of > that one? > > Adding here some related links: > https://groups.google.com/forum/#!msg/bitcoinj/Ys13qkTwcNg/9qxnhwnkeoIJ > https://eprint.iacr.org/2014/763.pdf > http://jonasnick.github.io/blog/2015/02/12/privacy-in-bitcoinj/ > > I assume you are sending a similar email to bitcoin-dev mailing list. > Looking forward to seeing what they will say. > > > > On Tue, Apr 23, 2019 at 8:43 AM Andreas Schildbach > <andr...@schildbach.de> wrote: >> >> 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. > > > > -- > Oscar Guindzberg > -- 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.
