MIME-Version: 1.0
In-Reply-To: <4A0CD31A-8745-4425-99FC-5DF12FA3B917@jonasschnelli.ch>
References: <paqids$e14$1@blaine.gmane.org>
	<4A0CD31A-8745-4425-99FC-5DF12FA3B917@jonasschnelli.ch>
From: Jim Posen <jim.posen@gmail.com>
Date: Fri, 13 Apr 2018 15:15:50 -0700
Message-ID: <CADZtCSjsLSr_A-cBG5weAgstW9RG0sDL1txHC_E9ksVL=xJ4uA@mail.gmail.com>
To: Andreas Schildbach <andreas@schildbach.de>
Content-Type: multipart/alternative; boundary="000000000000fa856f0569c236db"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BloomFilter issue with segwit addresses
Precedence: list

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

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 easy
> solution (CBloomFilter::IsRelevantAndUpdate())
>
> /jonas
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<div dir=3D"ltr">Why not add the outpoints owned by the wallet to the filte=
r and watch for those instead of elements in the input script or witness da=
ta?</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, =
Apr 13, 2018 at 12:12 PM, Jonas Schnelli via bitcoin-dev <span dir=3D"ltr">=
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex">Hi Andreas<br>
<br>
Thanks for bringing this up and this seems indeed to be suboptimal.<br>
<span class=3D""><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::<wbr>IsRelevantAndUpdate())<br>
<br>
/jonas<br>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>

--000000000000fa856f0569c236db--