{"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-31\n📝 Original message:Hi y'all,\n\nI've made a PR to the BIP repo to modify BIP 158 based on this thread, and\nother recent threads giving feedback on the current version of the BIP:\n\n  * https://github.com/bitcoin/bips/pull/687\n\nI've also updated the test vectors based on the current parameters (and\nfilter format), and also the code used to generate the test vectors. Due to\nthe change in parametrization, the test vectors now target (P=19 M=784931),\nand there're no longer any cases related to extended filters.\n\nOne notable thing that I left off is the proposed change to use the previous\noutput script rather than the outpoint. Modifying the filters in this\nfashion would be a downgrade in the security model for light clients, as it\nwould allow full nodes to lie by omission, just as they can with BIP 37. As\nis now, if nodes present conflicting information, then the light client can\ndownload the target block, fully reconstruct the filter itself, then ban any\nnodes which advertised the incorrect filter. The inclusion of the filter\nheader checkpoints make it rather straight forward for light clients to\nbisect the state to find the conflicting advertisement, and it's strongly\nrecommended that they do so.\n\nTo get a feel for the level of impact these changes would have on existing\napplications that depend on the txid being included in the filter, I've\nimplemented these changes across btcutil, btcd, btcwallet, and lnd (which\npreviously relied on the txid for confirmation notifications). For lnd at\nleast, the code impact was rather minimal, as we use the pkScript for\nmatching a block, but then still scan the block manually to find the precise\ntransaction (by txid) that we were interested in (if it's there).\n\n-- Laolu\n\n\nOn Mon, May 28, 2018 at 9:01 PM Olaoluwa Osuntokun \u003claolu32 at gmail.com\u003e\nwrote:\n\n\u003e \u003e The additional benefit of the input script/outpoint filter is to watch\n\u003e for\n\u003e \u003e unexpected spends (coins getting stolen or spent from another wallet) or\n\u003e \u003e transactions without a unique change or output address. I think this is a\n\u003e \u003e reasonable implementation, and it would be nice to be able to download\n\u003e that\n\u003e \u003e filter without any input elements.\n\u003e\n\u003e As someone who's implemented a complete integration of the filtering\n\u003e technique into an existing wallet, and a higher application I disagree.\n\u003e There's not much gain to be had in splitting up the filters: it'll result\n\u003e in\n\u003e additional round trips (to fetch these distinct filter) during normal\n\u003e operation, complicate routine seed rescanning logic, and also is\n\u003e detrimental\n\u003e to privacy if one is fetching blocks from the same peer as they've\n\u003e downloaded the filters from.\n\u003e\n\u003e However, I'm now convinced that the savings had by including the prev\n\u003e output\n\u003e script (addr re-use and outputs spent in the same block as they're created)\n\u003e outweigh the additional booking keeping required in an implementation (when\n\u003e extracting the precise tx that matched) compared to using regular outpoint\n\u003e as we do currently. Combined with the recently proposed re-parametrization\n\u003e of the gcs parameters[1], the filter size should shrink by quite a bit!\n\u003e\n\u003e I'm very happy with the review the BIPs has been receiving as of late. It\n\u003e would've been nice to have this 1+ year ago when the draft was initially\n\u003e proposed, but better late that never!\n\u003e\n\u003e Based on this thread, [1], and discussions on various IRC channels, I plan\n\u003e to make the following modifications to the BIP:\n\u003e\n\u003e   1. use P=2^19 and M=784931 as gcs parameters, and also bind these to the\n\u003e      filter instance, so future filter types may use distinct parameters\n\u003e   2. use the prev output script rather than the prev input script in the\n\u003e      regular filter\n\u003e   3. remove the txid from the regular filter(as with some extra\n\u003e book-keeping\n\u003e      the output script is enough)\n\u003e   4. do away with the extended filter all together, as our original use\n\u003e case\n\u003e      for it has been nerfed as the filter size grew too large when doing\n\u003e      recursive parsing. instead we watch for the outpoint being spent and\n\u003e      extract the pre-image from it if it matches now\n\u003e\n\u003e The resulting changes should slash the size of the filters, yet still\n\u003e ensure\n\u003e that they're useful enough for our target use case.\n\u003e\n\u003e [1]:\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/016029.html\n\u003e\n\u003e -- Laolu\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180531/5499982f/attachment-0001.html\u003e"}