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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1TwExw-0003I6-NM
for bitcoin-development@lists.sourceforge.net;
Fri, 18 Jan 2013 16:38:52 +0000
Received-SPF: pass (sog-mx-2.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;
Received: from mail-oa0-f43.google.com ([209.85.219.43])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1TwExv-00081V-F9
for bitcoin-development@lists.sourceforge.net;
Fri, 18 Jan 2013 16:38:52 +0000
Received: by mail-oa0-f43.google.com with SMTP id k1so4020643oag.2
for <bitcoin-development@lists.sourceforge.net>;
Fri, 18 Jan 2013 08:38:46 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.60.29.70 with SMTP id i6mr7685478oeh.38.1358527126140; Fri,
18 Jan 2013 08:38:46 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.128.139 with HTTP; Fri, 18 Jan 2013 08:38:45 -0800 (PST)
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: Fri, 18 Jan 2013 17:38:45 +0100
X-Google-Sender-Auth: kv8G3Zve08PKkmrsfUXOj0DgQPo
Message-ID: <CANEZrP3FMbCZzT0Lfajv7T=F=Sjv1pNW-f3JVyrZLH5tQxYfmw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Matt Corallo <bitcoin-list@bluematt.me>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.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
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: 1TwExv-00081V-F9
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: Fri, 18 Jan 2013 16:38:52 -0000
I'm thinking we should actually make the change we talked about before
and have the filtered block sent before the transaction data.
For one, it's not intuitive (API wise) that you'd get a callback
saying "new pending tx" immediately before another callback saying "tx
was confirmed", but that's what the current setup makes most natural.
To fix it we'd have to notice that a tx message wasn't requested by
us, buffer it, and wait for the corresponding filteredblock message.
It seems cleaner to receive a filteredblock and then for any tx that
matches it, attach it to the FilteredBlock object and wait until it is
full up, then pass it to the wallet code all at once.
Another issue is that to risk analyze unconfirmed transactions you
really have to download all dependencies. That has to be triggered by
seeing an unconfirmed transaction. It's dumb to start this process for
a tx that is actually in the chain, so you need to have some notion of
whether it came from a filtered block anyway. I only realized this
today.
I think when we discussed this before, the justification for having it
work the current way was that it was simpler to integrate with the SPV
client code if it was done this way around. But I don't think it's
really simpler. There are enough odd side effects of doing it this
way, that I feel it'd be better to tweak the protocol now whilst we
have the chance.
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
>
>
|
