It isn't being discussed atm (but was discussed 1 year ago when the BIP draft was originally published), as we're in the process of removing items or filters that aren't absolutely necessary. We're now at the point where there're no longer any items we can remove w/o making the filters less generally useful which signals a stopping point so we can begin widespread deployment.
In terms of a future extension, BIP 158 already defines custom filter types, and BIP 157 allows filters to be fetched in batch based on the block height and numerical range. The latter feature can later be modified to return a single composite filter rather than several individual filters. -- Laolu On Mon, Jun 4, 2018 at 7:28 AM Riccardo Casatta via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I was wondering why this multi-layer multi-block filter proposal isn't > getting any comment, > is it because not asking all filters is leaking information? > > Thanks > > Il giorno ven 18 mag 2018 alle ore 08:29 Karl-Johan Alm via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> ha scritto: > >> On Fri, May 18, 2018 at 12:25 AM, Matt Corallo via bitcoin-dev >> <bitcoin-dev@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) >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > > -- > Riccardo Casatta - @RCasatta <https://twitter.com/RCasatta> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
