1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1U37vx-0003eS-I1
for bitcoin-development@lists.sourceforge.net;
Wed, 06 Feb 2013 16:33:17 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.170 as permitted sender)
client-ip=209.85.214.170; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f170.google.com;
Received: from mail-ob0-f170.google.com ([209.85.214.170])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1U37vv-00028x-Qh
for bitcoin-development@lists.sourceforge.net;
Wed, 06 Feb 2013 16:33:17 +0000
Received: by mail-ob0-f170.google.com with SMTP id wc20so1660759obb.29
for <bitcoin-development@lists.sourceforge.net>;
Wed, 06 Feb 2013 08:33:10 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.182.159.98 with SMTP id xb2mr21988186obb.35.1360168390457;
Wed, 06 Feb 2013 08:33:10 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.86.169 with HTTP; Wed, 6 Feb 2013 08:33:10 -0800 (PST)
In-Reply-To: <CANEZrP1iV8K7_GQkRw6gNSXr+22MWmwuiu5651sK+QtupBSZtg@mail.gmail.com>
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>
<CANEZrP0HPgNKaNUMbFQS4Hj+gBQ6c7gatoeUXEiRSCA0wBkenA@mail.gmail.com>
<CANEZrP1iV8K7_GQkRw6gNSXr+22MWmwuiu5651sK+QtupBSZtg@mail.gmail.com>
Date: Wed, 6 Feb 2013 17:33:10 +0100
X-Google-Sender-Auth: SisW1EJpkqd5LSfuMEo_-4LIHOE
Message-ID: <CANEZrP3WGbm9sZa7HnA1gHWNdMbREsvnTiU=bRR0hx+5=9BELA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Matt Corallo <bitcoin-list@bluematt.me>
Content-Type: multipart/alternative; boundary=14dae9399a4dbf7a0704d510e17f
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1U37vv-00028x-Qh
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Draft BIP for Bloom filtering
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 06 Feb 2013 16:33:17 -0000
--14dae9399a4dbf7a0704d510e17f
Content-Type: text/plain; charset=UTF-8
Can somebody please unlock the BIP wiki page? I don't know why it was
locked but it's stale.
On Wed, Jan 30, 2013 at 12:13 PM, Mike Hearn <mike@plan99.net> wrote:
> Sorry, to clarify, these are test builds available here:
>
>
> https://code.google.com/p/bitcoin-wallet/downloads/detail?name=bitcoin-wallet-2.39_bitcoinj0.7.apk&can=2&q=
>
> It's not on the Play store yet. It probably makes sense to release after
> some more testing and after Bitcoin 0.8 comes out, as otherwise there's a
> risk that 0.7 snapshot nodes will get overloaded.
>
>
> On Wed, Jan 30, 2013 at 12:09 PM, Mike Hearn <mike@plan99.net> wrote:
>
>> 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
>>>
>>>
>>>
>>
>
--14dae9399a4dbf7a0704d510e17f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Can somebody please unlock the BIP wiki page? I don't =
know why it was locked but it's stale.</div><div class=3D"gmail_extra">=
<br><br><div class=3D"gmail_quote">On Wed, Jan 30, 2013 at 12:13 PM, Mike H=
earn <span dir=3D"ltr"><<a href=3D"mailto:mike@plan99.net" target=3D"_bl=
ank">mike@plan99.net</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Sorry, to clarify, these ar=
e test builds available here:<div><br></div><div>=C2=A0=C2=A0<a href=3D"htt=
ps://code.google.com/p/bitcoin-wallet/downloads/detail?name=3Dbitcoin-walle=
t-2.39_bitcoinj0.7.apk&can=3D2&q=3D" target=3D"_blank">https://code=
.google.com/p/bitcoin-wallet/downloads/detail?name=3Dbitcoin-wallet-2.39_bi=
tcoinj0.7.apk&can=3D2&q=3D</a><br>
</div><div><br></div><div>It's not on the Play store yet. It probably m=
akes sense to release after some more testing and after Bitcoin 0.8 comes o=
ut, as otherwise there's a risk that 0.7 snapshot nodes will get overlo=
aded.</div>
</div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra"><b=
r><br><div class=3D"gmail_quote">On Wed, Jan 30, 2013 at 12:09 PM, Mike Hea=
rn <span dir=3D"ltr"><<a href=3D"mailto:mike@plan99.net" target=3D"_blan=
k">mike@plan99.net</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<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>The performance gain is very cool. The app feels dr=
amatically faster to start up and sync. Because the app syncs on charge whe=
n I opened it around lunchtime it had only 7 hours of data to sync (42 bloc=
ks) and it brought up 6 peer connections, found a 0.7.99 node and synced al=
l in <2 seconds. That was on wifi.</div>
<div><br></div><div>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 fas=
t catchup for first time users.</div>
<div><br></div><div>The BIP is now a little bit stale, but only slightly.</=
div></div><div><div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_=
quote">On Wed, Jan 16, 2013 at 4:00 PM, Matt Corallo <span dir=3D"ltr"><=
<a href=3D"mailto:bitcoin-list@bluematt.me" target=3D"_blank">bitcoin-list@=
bluematt.me</a>></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'll have that finished up by the end of today.<br>
<span><font color=3D"#888888"><br>
Matt<br>
</font></span><div><div><br>
On Wed, 2013-01-16 at 11:43 +0100, Mike Hearn wrote:<br>
> Matts latest code has been tested by Andreas and seems to work<br>
> correctly. He had to extend the client a bit to refresh the filter<br>
> every 25k blocks because even with the extra flag, eventually the<br>
> filter degrades into uselessness, but it did still improve the<br>
> situation quite a bit.<br>
><br>
> Because it's unit tested, been reviewed by me several times, has a=
n<br>
> interoperable implementation that has also been tested by Andreas in a=
<br>
> build of his smartphone app, =C2=A0I'm going to ACK the current co=
de and<br>
> request that it be merged in to 0.8. What do you say Gavin?<br>
><br>
> The next step after that would be profiling. It's a big performanc=
e<br>
> improvement for SPV clients already, but not as much as I anticipated.=
<br>
> I suspect there's a simple bottleneck or missed optimization<br>
> somewhere. But that can obviously come post-0.8<br>
<br>
<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
--14dae9399a4dbf7a0704d510e17f--
|
