To Christian's point about privacy, I'll take this opportunity to
shamelessly review beg on https://github.com/bitcoin/bitcoin/pull/12254,
the PR for BIP 158 implementation (but not 157).

On Sat, Apr 14, 2018 at 9:14 AM, Christian Decker <
decker.christian@gmail.com> wrote:

> Note that this would compound the privacy leak that Jonas Nick used to
> identify address clusters via the bloom filters in one of his publications.
> By reducing the false positives when matching you can get very detailed
> clusters. Then again we know that bloom filters aren't good for privacy
> anyway, so this might be a non-issue.
>
> On Sat, Apr 14, 2018, 00:17 Jim Posen via bitcoin-dev <bitcoin-dev@lists.
> linuxfoundation.org> wrote:
>
>> Why not add the outpoints owned by the wallet to the filter and watch for
>> those instead of elements in the input script or witness data?
>>
>> On Fri, Apr 13, 2018 at 12:12 PM, Jonas Schnelli via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Hi Andreas
>>>
>>> Thanks for bringing this up and this seems indeed to be suboptimal.
>>>
>>> > I wonder if Bitcoin Core would be willing to extend the BIP37 matching
>>> > rules such that data elements in the witness are also matched against?
>>>
>>> Bitcoin Core is not an identity that can be „willing to extend“ (or
>>> reject) a feature.
>>> Someone needs to come up with a proposal (pull request).
>>>
>>> Maybe an extension for BIP37 would make sense (*meh*).
>>> Just inserting the witness data into the bloom filter seems to be an
>>> easy solution (CBloomFilter::IsRelevantAndUpdate())
>>>
>>> /jonas
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>