rich1.0npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwethttps://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetnjumphttps://nostr.ae📅 Original date posted:2018-06-02 📝 Original message:On Sat, Jun 2, 2018 at 10:02 PM, Tamas Blummer via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote: > Years of experience implementing wallets with BIP 37 pretty much us that all these filter things are a total waste of time. BIP37 use is nearly dead on the network-- monitor your own nodes to see the actual use of the filters: it's very low. I see under average of 1 peer per day using it. Moreover the primary complaint from users about BIP37 vs the alternatives they're choosing over it (electrum and web wallets) is that the sync time is too long-- something BIP158 doesn't improve. So if we were going to go based on history we wouldn't bother with on P2P at all. But I think the history's lesson here may mostly be an accident, and that the the non-use of BIP37 is due more to the low quality and/or abandoned status of most BIP37 implementing software, rather than a fundamental lack of utility. Though maybe we do find out that once someone bothers implementing a PIR based scanning mechanism (as electrum has talked about on and off for a while now) we'll lose another advantage. BIP37 also got a number of things wrong-- what went into the filters was a big element in that (causing massive pollution of matches due to useless data), along with privacy etc. This kind of approach will have the best chances if it doesn't repeat the mistakes... but also it'll have the best chances if it has good security, and getting SPV- equivalent security will require committing the filters, but committing them is a big step because then the behaviour becomes consensus normative-- it's worth spending a few months of extra iteration getting the design as good as possible before doing that (which is what we've been seeing lately).