{"type":"rich","version":"1.0","author_name":"npub1ppn2nhlfdzkw9gw0ytljpef5dpyzsxzw8ffcyykamt32hw6pge0smhs2fw","author_url":"https://nostr.ae/npub1ppn2nhlfdzkw9gw0ytljpef5dpyzsxzw8ffcyykamt32hw6pge0smhs2fw","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2018-05-22\n📝 Original message:Maybe I didn't make it clear, but the distinction is that the current track\nallocates\none service bit for each \"filter type\", where it has to be agreed upon up\nfront what\nelements such a filter type contains.\n\nMy suggestion was to advertise a bitfield for each filter type the node\nserves,\nwhere the bitfield indicates what elements are part of the filters. This\nessentially\nremoves the notion of decided filter types and instead leaves the decision\nto\nfull-nodes.\n\nThis would require a \"getcftypes\" message, of course.\n\n- Johan\n\n\nOn Tue, May 22, 2018 at 3:16 AM, Olaoluwa Osuntokun \u003claolu32 at gmail.com\u003e\nwrote:\n\n\u003e \u003e What if instead of trying to decide up front which subset of elements\n\u003e will\n\u003e \u003e be most useful to include in the filters, and the size tradeoff, we let\n\u003e the\n\u003e \u003e full-node decide which subsets of elements it serves filters for?\n\u003e\n\u003e This is already the case. The current \"track\" is to add new service bits\n\u003e (while we're in the uncommitted phase) to introduce new fitler types. Light\n\u003e clients can then filter out nodes before even connecting to them.\n\u003e\n\u003e -- Laolu\n\u003e\n\u003e On Mon, May 21, 2018 at 1:35 AM Johan Torås Halseth \u003cjohanth at gmail.com\u003e\n\u003e wrote:\n\u003e\n\u003e\u003e Hi all,\n\u003e\u003e\n\u003e\u003e Most light wallets will want to download the minimum amount of data\n\u003e\u003e required to operate, which means they would ideally download the smallest\n\u003e\u003e possible filters containing the subset of elements they need.\n\u003e\u003e\n\u003e\u003e What if instead of trying to decide up front which subset of elements\n\u003e\u003e will be most useful to include in the filters, and the size tradeoff, we\n\u003e\u003e let the full-node decide which subsets of elements it serves filters for?\n\u003e\u003e\n\u003e\u003e For instance, a full node would advertise that it could serve filters for\n\u003e\u003e the subsets 110 (txid+script+outpoint), 100 (txid only), 011 (script+outpoint)\n\u003e\u003e etc. A light client could then choose to download the minimal filter type\n\u003e\u003e covering its needs.\n\u003e\u003e\n\u003e\u003e The obvious benefit of this would be minimal bandwidth usage for the\n\u003e\u003e light client, but there are also some less obvious ones. We wouldn’t have\n\u003e\u003e to decide up front what each filter type should contain, only the possible\n\u003e\u003e elements a filter can contain (more can be added later without breaking\n\u003e\u003e existing clients). This, I think, would let the most served filter types\n\u003e\u003e grow organically, with full-node implementations coming with sane defaults\n\u003e\u003e for served filter types (maybe even all possible types as long as the\n\u003e\u003e number of elements is small), letting their operator add/remove types at\n\u003e\u003e will.\n\u003e\u003e\n\u003e\u003e The main disadvantage of this as I see it, is that there’s an exponential\n\u003e\u003e blowup in the number of possible filter types in the number of element\n\u003e\u003e types. However, this would let us start out small with only the elements we\n\u003e\u003e need, and in the worst case the node operators just choose to serve the\n\u003e\u003e subsets corresponding to what now is called “regular” + “extended” filters\n\u003e\u003e anyway, requiring no more resources.\n\u003e\u003e\n\u003e\u003e This would also give us some data on what is the most widely used filter\n\u003e\u003e types, which could be useful in making the decision on what should be part\n\u003e\u003e of filters to eventually commit to in blocks.\n\u003e\u003e\n\u003e\u003e - Johan\n\u003e\u003e On Sat, May 19, 2018 at 5:12, Olaoluwa Osuntokun via bitcoin-dev \u003c\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e On Thu, May 17, 2018 at 2:44 PM Jim Posen via bitcoin-dev \u003cbitcoin-\n\u003e\u003e\n\u003e\u003e\u003e Monitoring inputs by scriptPubkey vs input-txid also has a massive\n\u003e\u003e\u003e\u003e advantage for parallel filtering: You can usually known your pubkeys\n\u003e\u003e\u003e\u003e well in advance, but if you have to change what you're watching block\n\u003e\u003e\u003e\u003e N+1 for based on the txids that paid you in N you can't filter them\n\u003e\u003e\u003e\u003e in parallel.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e Yes, I'll grant that this is a benefit of your suggestion.\n\u003e\u003e\u003e\n\u003e\u003e\n\u003e\u003e Yeah parallel filtering would be pretty nice. We've implemented a serial\n\u003e\u003e filtering for btcwallet [1] for the use-case of rescanning after a seed\n\u003e\u003e phrase import. Parallel filtering would help here, but also we don't yet\n\u003e\u003e take advantage of batch querying for the filters themselves. This would\n\u003e\u003e speed up the scanning by quite a bit.\n\u003e\u003e\n\u003e\u003e I really like the filtering model though, it really simplifies the code,\n\u003e\u003e and we can leverage identical logic for btcd (which has RPCs to fetch the\n\u003e\u003e filters) as well.\n\u003e\u003e\n\u003e\u003e [1]: https://github.com/Roasbeef/btcwallet/blob/master/chain/\n\u003e\u003e neutrino.go#L180\n\u003e\u003e\n\u003e\u003e _______________________________________________ bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org https://lists.linuxfoundation.\n\u003e\u003e org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180522/cdeb1da6/attachment.html\u003e"}