MIME-Version: 1.0
References: <paqids$e14$1@blaine.gmane.org>
	<4A0CD31A-8745-4425-99FC-5DF12FA3B917@jonasschnelli.ch>
	<CADZtCSjsLSr_A-cBG5weAgstW9RG0sDL1txHC_E9ksVL=xJ4uA@mail.gmail.com>
In-Reply-To: <CADZtCSjsLSr_A-cBG5weAgstW9RG0sDL1txHC_E9ksVL=xJ4uA@mail.gmail.com>
From: Christian Decker <decker.christian@gmail.com>
Date: Sat, 14 Apr 2018 16:14:04 +0000
Message-ID: <CALxbBHV=xpzu8iL-S=EKBc39QWvAiicVixM_j3Ve1TH+sngPoQ@mail.gmail.com>
To: Jim Posen <jim.posen@gmail.com>, Bitcoin development mailing list
	<bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="f4f5e807ac4cae92b20569d14722"
Subject: Re: [bitcoin-dev] BloomFilter issue with segwit addresses
Precedence: list

--f4f5e807ac4cae92b20569d14722
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 =E2=80=9Ewilling to extend=
=E2=80=9C (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 eas=
y
>> 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
>

--f4f5e807ac4cae92b20569d14722
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">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 ve=
ry detailed clusters. Then again we know that bloom filters aren&#39;t good=
 for privacy anyway, so this might be a non-issue.</div><br><div class=3D"g=
mail_quote"><div dir=3D"ltr">On Sat, Apr 14, 2018, 00:17 Jim Posen via bitc=
oin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoi=
n-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">Why not add the outpoints owned by the walle=
t to the filter and watch for those instead of elements in the input script=
 or witness data?</div><div class=3D"gmail_extra"><br><div class=3D"gmail_q=
uote">On Fri, Apr 13, 2018 at 12:12 PM, Jonas Schnelli via bitcoin-dev <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
target=3D"_blank" rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org<=
/a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Andreas<br>
<br>
Thanks for bringing this up and this seems indeed to be suboptimal.<br>
<span><br>
&gt; I wonder if Bitcoin Core would be willing to extend the BIP37 matching=
<br>
&gt; rules such that data elements in the witness are also matched against?=
<br>
<br>
</span>Bitcoin Core is not an identity that can be =E2=80=9Ewilling to exte=
nd=E2=80=9C (or reject) a feature.<br>
Someone needs to come up with a proposal (pull request).<br>
<br>
Maybe an extension for BIP37 would make sense (*meh*).<br>
Just inserting the witness data into the bloom filter seems to be an easy s=
olution (CBloomFilter::IsRelevantAndUpdate())<br>
<br>
/jonas<br>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--f4f5e807ac4cae92b20569d14722--