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