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.
