rich1.0npub17cwk7hm623dm5npjzu8cvv994h43k2keanegs8w78xyvlez8hqqsqqmtzyhttps://nostr.ae/npub17cwk7hm623dm5npjzu8cvv994h43k2keanegs8w78xyvlez8hqqsqqmtzynjumphttps://nostr.ae📅 Original date posted:2018-05-18 📝 Original message:On Fri, May 18, 2018 at 12:25 AM, Matt Corallo via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote: > In general, I'm concerned about the size of the filters making existing > SPV clients less willing to adopt BIP 158 instead of the existing bloom > filter garbage and would like to see a further exploration of ways to > split out filters to make them less bandwidth intensive. Some further > ideas we should probably play with before finalizing moving forward is > providing filters for certain script templates, eg being able to only > get outputs that are segwit version X or other similar ideas. There is also the idea of multi-block filters. The idea is that light clients would download a pair of filters for blocks X..X+255 and X+256..X+511, check if they have any matches and then grab pairs for any that matched, e.g. X..X+127 & X+128..X+255 if left matched, and iterate down until it ran out of hits-in-a-row or it got down to single-block level. This has an added benefit where you can accept a slightly higher false positive rate for bigger ranges, because the probability of a specific entry having a false positive in each filter is (empirically speaking) independent. I.e. with a FP probability of 1% in the 256 range block and a FP probability of 0.1% in the 128 range block would mean the probability is actually 0.001%. Wrote about this here: https://bc-2.jp/bfd-profile.pdf (but the filter type is different in my experiments)