{"type":"rich","version":"1.0","author_name":"npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4","author_url":"https://nostr.ae/npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2018-05-29\n📝 Original message:\u003e The additional benefit of the input script/outpoint filter is to watch for\n\u003e unexpected spends (coins getting stolen or spent from another wallet) or\n\u003e transactions without a unique change or output address. I think this is a\n\u003e reasonable implementation, and it would be nice to be able to download\nthat\n\u003e filter without any input elements.\n\nAs someone who's implemented a complete integration of the filtering\ntechnique into an existing wallet, and a higher application I disagree.\nThere's not much gain to be had in splitting up the filters: it'll result in\nadditional round trips (to fetch these distinct filter) during normal\noperation, complicate routine seed rescanning logic, and also is detrimental\nto privacy if one is fetching blocks from the same peer as they've\ndownloaded the filters from.\n\nHowever, I'm now convinced that the savings had by including the prev output\nscript (addr re-use and outputs spent in the same block as they're created)\noutweigh the additional booking keeping required in an implementation (when\nextracting the precise tx that matched) compared to using regular outpoint\nas we do currently. Combined with the recently proposed re-parametrization\nof the gcs parameters[1], the filter size should shrink by quite a bit!\n\nI'm very happy with the review the BIPs has been receiving as of late. It\nwould've been nice to have this 1+ year ago when the draft was initially\nproposed, but better late that never!\n\nBased on this thread, [1], and discussions on various IRC channels, I plan\nto make the following modifications to the BIP:\n\n  1. use P=2^19 and M=784931 as gcs parameters, and also bind these to the\n     filter instance, so future filter types may use distinct parameters\n  2. use the prev output script rather than the prev input script in the\n     regular filter\n  3. remove the txid from the regular filter(as with some extra book-keeping\n     the output script is enough)\n  4. do away with the extended filter all together, as our original use case\n     for it has been nerfed as the filter size grew too large when doing\n     recursive parsing. instead we watch for the outpoint being spent and\n     extract the pre-image from it if it matches now\n\nThe resulting changes should slash the size of the filters, yet still ensure\nthat they're useful enough for our target use case.\n\n[1]:\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/016029.html\n\n-- Laolu\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180528/8326d73b/attachment-0001.html\u003e"}