MIME-Version: 1.0
References: <d43c6082-1b2c-c95b-5144-99ad0021ea6c@mattcorallo.com>
	<CAAS2fgRF-MhOvpFY6c_qAPzNMo3GQ28RExdSbOV6Q6Oy2iWn1A@mail.gmail.com>
	<22d375c7-a032-8691-98dc-0e6ee87a4b08@mattcorallo.com>
	<CAAS2fgR3QRHeHEjjOS1ckEkL-h7=Na56G12hYW9Bmy9WEMduvg@mail.gmail.com>
	<CADZtCShLmH_k-UssNWahUNHgHvWQQ1y638LwaOfnJEipwjbiYg@mail.gmail.com>
	<CAAS2fgQLCN_cuZ-3QPjCLfYOtHfEk=SenTn5=y9LfGzJxLPR3Q@mail.gmail.com>
	<CADZtCSjYr6VMBVQ=rx44SgRWcFSXhVXUZJB=rHMh4X78Z2eY1A@mail.gmail.com>
In-Reply-To: <CADZtCSjYr6VMBVQ=rx44SgRWcFSXhVXUZJB=rHMh4X78Z2eY1A@mail.gmail.com>
From: Olaoluwa Osuntokun <laolu32@gmail.com>
Date: Fri, 18 May 2018 20:12:09 -0700
Message-ID: <CAO3Pvs9K3n=OzVQ06XGQvzNC+Aqp9S60kWM9VRPA8hWTJ3u9BQ@mail.gmail.com>
To: Jim Posen <jim.posen@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000e3a647056c866f1e"
Subject: Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size
Precedence: list

--000000000000e3a647056c866f1e
Content-Type: text/plain; charset="UTF-8"

On Thu, May 17, 2018 at 2:44 PM Jim Posen via bitcoin-dev <bitcoin-

> Monitoring inputs by scriptPubkey vs input-txid also has a massive
>> advantage for parallel filtering:  You can usually known your pubkeys
>> well in advance, but if you have to change what you're watching block
>>  N+1 for based on the txids that paid you in N you can't filter them
>> in parallel.
>>
>
> Yes, I'll grant that this is a benefit of your suggestion.
>

Yeah parallel filtering would be pretty nice. We've implemented a serial
filtering for btcwallet [1] for the use-case of rescanning after a seed
phrase import. Parallel filtering would help here, but also we don't yet
take advantage of batch querying for the filters themselves. This would
speed up the scanning by quite a bit.

I really like the filtering model though, it really simplifies the code,
and we can leverage identical logic for btcd (which has RPCs to fetch the
filters) as well.

[1]:
https://github.com/Roasbeef/btcwallet/blob/master/chain/neutrino.go#L180

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, May 17=
, 2018 at 2:44 PM Jim Posen via bitcoin-dev &lt;bitcoin-=C2=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div cl=
ass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex">Monitoring inputs by scr=
iptPubkey vs input-txid also has a massive<br>
advantage for parallel filtering:=C2=A0 You can usually known your pubkeys<=
br>
well in advance, but if you have to change what you&#39;re watching block<b=
r>
=C2=A0N+1 for based on the txids that paid you in N you can&#39;t filter th=
em<br>
in parallel.<br></blockquote><div><br></div></div></div></div><div dir=3D"l=
tr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>Yes, I&#39;l=
l grant that this is a benefit of your suggestion.</div></div></div></div><=
/blockquote><div><br></div><div>Yeah parallel filtering would be pretty nic=
e. We&#39;ve implemented a serial filtering for btcwallet [1] for the use-c=
ase of rescanning after a seed phrase import. Parallel filtering would help=
 here, but also we don&#39;t yet take advantage of batch querying for the f=
ilters themselves. This would speed up the scanning by quite a bit.=C2=A0</=
div><div><br></div><div>I really like the filtering model though, it really=
 simplifies the code, and we can leverage identical logic for btcd (which h=
as RPCs to fetch the filters) as well.=C2=A0</div><div><br></div><div>[1]:=
=C2=A0<a href=3D"https://github.com/Roasbeef/btcwallet/blob/master/chain/ne=
utrino.go#L180">https://github.com/Roasbeef/btcwallet/blob/master/chain/neu=
trino.go#L180</a>=C2=A0</div></div></div>

--000000000000e3a647056c866f1e--