Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.219.43 as permitted sender)
	client-ip=209.85.219.43; envelope-from=mh.in.england@gmail.com;
	helo=mail-oa0-f43.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <1358348447.1048.0.camel@localhost.localdomain>
References: <CANEZrP0XALwBFJyZTzYd5xBp4MRrjv0s_y2tOXbO7UgjWF2HzA@mail.gmail.com>
	<20121121151534.GA5540@vps7135.xlshosting.net>
	<1353523117.1085.14.camel@localhost.localdomain>
	<20121127211019.GA22701@vps7135.xlshosting.net>
	<CANEZrP0w052ebao-04H4Wduerm86o6RKBY=ObnJXBX22k--zMA@mail.gmail.com>
	<1357876751.1740.4.camel@localhost.localdomain>
	<CA+8xBpcB6kXWyRbeUknK6gkcrFMV6YtrDk0c938q1_32U6GtRw@mail.gmail.com>
	<CANEZrP2k30UsWFYSZ7Bh5Hm4LJ9vEAMEUgYSrYkcXcDTY2Z79Q@mail.gmail.com>
	<CANEZrP3KKGOPM7BzWAr1xGqh96iEzJ+Ki2hdUTe0Gvv51pJ23w@mail.gmail.com>
	<CANEZrP2q=Kvk8DRRjB7mtw7QF8xDTAFYPVRCDW60tJn4A67LYQ@mail.gmail.com>
	<1358348447.1048.0.camel@localhost.localdomain>
Date: Wed, 30 Jan 2013 12:09:55 +0100
Message-ID: <CANEZrP0HPgNKaNUMbFQS4Hj+gBQ6c7gatoeUXEiRSCA0wBkenA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Matt Corallo <bitcoin-list@bluematt.me>
Content-Type: multipart/alternative; boundary=e89a8fb1ebc2ddcd4104d47f8cc8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Draft BIP for Bloom filtering
Precedence: list

--e89a8fb1ebc2ddcd4104d47f8cc8
Content-Type: text/plain; charset=UTF-8

Andreas has uploaded Android builds that use the new bloom filtering and
peer selection code (also, dependency analysis of transactions).

The performance gain is very cool. The app feels dramatically faster to
start up and sync. Because the app syncs on charge when I opened it around
lunchtime it had only 7 hours of data to sync (42 blocks) and it brought up
6 peer connections, found a 0.7.99 node and synced all in <2 seconds. That
was on wifi.

The next lowest hanging perf fruit is almost certainly to optimize disk
accesses. Flash on Android devices seems to be much slower than laptop
flash storage, and current bitcoinj is very inefficient in how it writes
(one write per block header!). This matters a lot when doing fast catchup
for first time users.

The BIP is now a little bit stale, but only slightly.


On Wed, Jan 16, 2013 at 4:00 PM, Matt Corallo <bitcoin-list@bluematt.me>wrote:

> Actually, there is one more minor algorithmic change I would like to
> make to the way the hash function is computed really quick before it
> gets merged, I'll have that finished up by the end of today.
>
> Matt
>
> On Wed, 2013-01-16 at 11:43 +0100, Mike Hearn wrote:
> > Matts latest code has been tested by Andreas and seems to work
> > correctly. He had to extend the client a bit to refresh the filter
> > every 25k blocks because even with the extra flag, eventually the
> > filter degrades into uselessness, but it did still improve the
> > situation quite a bit.
> >
> > Because it's unit tested, been reviewed by me several times, has an
> > interoperable implementation that has also been tested by Andreas in a
> > build of his smartphone app,  I'm going to ACK the current code and
> > request that it be merged in to 0.8. What do you say Gavin?
> >
> > The next step after that would be profiling. It's a big performance
> > improvement for SPV clients already, but not as much as I anticipated.
> > I suspect there's a simple bottleneck or missed optimization
> > somewhere. But that can obviously come post-0.8
>
>
>

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

<div dir=3D"ltr">Andreas has uploaded Android builds that use the new bloom=
 filtering and peer selection code (also, dependency analysis of transactio=
ns).<div><br></div><div style>The performance gain is very cool. The app fe=
els dramatically faster to start up and sync. Because the app syncs on char=
ge when I opened it around lunchtime it had only 7 hours of data to sync (4=
2 blocks) and it brought up 6 peer connections, found a 0.7.99 node and syn=
ced all in &lt;2 seconds. That was on wifi.</div>
<div style><br></div><div style>The next lowest hanging perf fruit is almos=
t certainly to optimize disk accesses. Flash on Android devices seems to be=
 much slower than laptop flash storage, and current bitcoinj is very ineffi=
cient in how it writes (one write per block header!). This matters a lot wh=
en doing fast catchup for first time users.</div>
<div style><br></div><div style>The BIP is now a little bit stale, but only=
 slightly.</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmai=
l_quote">On Wed, Jan 16, 2013 at 4:00 PM, Matt Corallo <span dir=3D"ltr">&l=
t;<a href=3D"mailto:bitcoin-list@bluematt.me" target=3D"_blank">bitcoin-lis=
t@bluematt.me</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Actually, there is one more minor algorithmi=
c change I would like to<br>
make to the way the hash function is computed really quick before it<br>
gets merged, I&#39;ll have that finished up by the end of today.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Matt<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
On Wed, 2013-01-16 at 11:43 +0100, Mike Hearn wrote:<br>
&gt; Matts latest code has been tested by Andreas and seems to work<br>
&gt; correctly. He had to extend the client a bit to refresh the filter<br>
&gt; every 25k blocks because even with the extra flag, eventually the<br>
&gt; filter degrades into uselessness, but it did still improve the<br>
&gt; situation quite a bit.<br>
&gt;<br>
&gt; Because it&#39;s unit tested, been reviewed by me several times, has a=
n<br>
&gt; interoperable implementation that has also been tested by Andreas in a=
<br>
&gt; build of his smartphone app, =C2=A0I&#39;m going to ACK the current co=
de and<br>
&gt; request that it be merged in to 0.8. What do you say Gavin?<br>
&gt;<br>
&gt; The next step after that would be profiling. It&#39;s a big performanc=
e<br>
&gt; improvement for SPV clients already, but not as much as I anticipated.=
<br>
&gt; I suspect there&#39;s a simple bottleneck or missed optimization<br>
&gt; somewhere. But that can obviously come post-0.8<br>
<br>
<br>
</div></div></blockquote></div><br></div>

--e89a8fb1ebc2ddcd4104d47f8cc8--