<div dir="ltr"><div>Hi y&#39;all, </div><div><br></div><div>I&#39;ve made a PR to the BIP repo to modify BIP 158 based on this thread, and</div><div>other recent threads giving feedback on the current version of the BIP:</div><div><br></div><div>  * <a href="https://github.com/bitcoin/bips/pull/687">https://github.com/bitcoin/bips/pull/687</a></div><div><br></div><div>I&#39;ve also updated the test vectors based on the current parameters (and</div><div>filter format), and also the code used to generate the test vectors. Due to</div><div>the change in parametrization, the test vectors now target (P=19 M=784931),</div><div>and there&#39;re no longer any cases related to extended filters.</div><div><br></div><div>One notable thing that I left off is the proposed change to use the previous</div><div>output script rather than the outpoint. Modifying the filters in this</div><div>fashion would be a downgrade in the security model for light clients, as it</div><div>would allow full nodes to lie by omission, just as they can with BIP 37. As</div><div>is now, if nodes present conflicting information, then the light client can</div><div>download the target block, fully reconstruct the filter itself, then ban any</div><div>nodes which advertised the incorrect filter. The inclusion of the filter</div><div>header checkpoints make it rather straight forward for light clients to</div><div>bisect the state to find the conflicting advertisement, and it&#39;s strongly</div><div>recommended that they do so.</div><div><br></div><div>To get a feel for the level of impact these changes would have on existing</div><div>applications that depend on the txid being included in the filter, I&#39;ve</div><div>implemented these changes across btcutil, btcd, btcwallet, and lnd (which</div><div>previously relied on the txid for confirmation notifications). For lnd at</div><div>least, the code impact was rather minimal, as we use the pkScript for</div><div>matching a block, but then still scan the block manually to find the precise</div><div>transaction (by txid) that we were interested in (if it&#39;s there).</div><div><br></div><div>-- Laolu</div><div><br></div><br><div class="gmail_quote"><div dir="ltr">On Mon, May 28, 2018 at 9:01 PM Olaoluwa Osuntokun &lt;<a href="mailto:laolu32@gmail.com">laolu32@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>&gt; The additional benefit of the input script/outpoint filter is to watch for<br></div></div><div dir="ltr"><div><div>&gt; unexpected spends (coins getting stolen or spent from another wallet) or</div><div>&gt; transactions without a unique change or output address. I think this is a</div><div>&gt; reasonable implementation, and it would be nice to be able to download that</div><div>&gt; filter without any input elements. </div><div><br></div></div></div><div dir="ltr"><div><div>As someone who&#39;s implemented a complete integration of the filtering</div><div>technique into an existing wallet, and a higher application I disagree.</div><div>There&#39;s not much gain to be had in splitting up the filters: it&#39;ll result in</div><div>additional round trips (to fetch these distinct filter) during normal</div><div>operation, complicate routine seed rescanning logic, and also is detrimental</div><div>to privacy if one is fetching blocks from the same peer as they&#39;ve</div><div>downloaded the filters from.</div><div><br></div><div>However, I&#39;m now convinced that the savings had by including the prev output</div><div>script (addr re-use and outputs spent in the same block as they&#39;re created)</div><div>outweigh the additional booking keeping required in an implementation (when</div><div>extracting the precise tx that matched) compared to using regular outpoint</div><div>as we do currently. Combined with the recently proposed re-parametrization</div><div>of the gcs parameters[1], the filter size should shrink by quite a bit!</div><div><br></div><div>I&#39;m very happy with the review the BIPs has been receiving as of late. It</div><div>would&#39;ve been nice to have this 1+ year ago when the draft was initially</div><div>proposed, but better late that never!</div><div><br></div><div>Based on this thread, [1], and discussions on various IRC channels, I plan</div><div>to make the following modifications to the BIP:</div><div><br></div><div>  1. use P=2^19 and M=784931 as gcs parameters, and also bind these to the</div><div>     filter instance, so future filter types may use distinct parameters</div><div>  2. use the prev output script rather than the prev input script in the</div><div>     regular filter</div><div>  3. remove the txid from the regular filter(as with some extra book-keeping</div><div>     the output script is enough) </div><div>  4. do away with the extended filter all together, as our original use case</div><div>     for it has been nerfed as the filter size grew too large when doing</div><div>     recursive parsing. instead we watch for the outpoint being spent and</div><div>     extract the pre-image from it if it matches now</div><div><br></div><div>The resulting changes should slash the size of the filters, yet still ensure</div><div>that they&#39;re useful enough for our target use case.</div><div><br></div><div>[1]: <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/016029.html" target="_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/016029.html</a></div><div><br></div><div>-- Laolu</div></div></div></blockquote></div></div>