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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gcbd-bitcoin-development@m.gmane.org>)
id 1TwVJn-0006Bc-R0 for bitcoin-development@lists.sourceforge.net;
Sat, 19 Jan 2013 10:06:31 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of m.gmane.org
designates 80.91.229.3 as permitted sender)
client-ip=80.91.229.3;
envelope-from=gcbd-bitcoin-development@m.gmane.org;
helo=plane.gmane.org;
Received: from plane.gmane.org ([80.91.229.3])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1TwVJm-0002an-B1
for bitcoin-development@lists.sourceforge.net;
Sat, 19 Jan 2013 10:06:31 +0000
Received: from list by plane.gmane.org with local (Exim 4.69)
(envelope-from <gcbd-bitcoin-development@m.gmane.org>)
id 1TwV5G-000590-Bl for bitcoin-development@lists.sourceforge.net;
Sat, 19 Jan 2013 10:51:30 +0100
Received: from e178187115.adsl.alicedsl.de ([85.178.187.115])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00 for <bitcoin-development@lists.sourceforge.net>;
Sat, 19 Jan 2013 10:51:30 +0100
Received: from andreas by e178187115.adsl.alicedsl.de with local (Gmexim 0.1
(Debian)) id 1AlnuQ-0007hv-00
for <bitcoin-development@lists.sourceforge.net>;
Sat, 19 Jan 2013 10:51:30 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: bitcoin-development@lists.sourceforge.net
From: Andreas Schildbach <andreas@schildbach.de>
Date: Sat, 19 Jan 2013 10:51:04 +0100
Message-ID: <50FA6C88.1030102@schildbach.de>
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>
<CANEZrP3FMbCZzT0Lfajv7T=F=Sjv1pNW-f3JVyrZLH5tQxYfmw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: e178187115.adsl.alicedsl.de
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:17.0) Gecko/20130106 Thunderbird/17.0.2
In-Reply-To: <CANEZrP3FMbCZzT0Lfajv7T=F=Sjv1pNW-f3JVyrZLH5tQxYfmw@mail.gmail.com>
X-Spam-Score: -0.4 (/)
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 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [80.91.229.3 listed in list.dnswl.org]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
1.1 DKIM_ADSP_ALL No valid author signature,
domain signs all mail
-0.0 SPF_PASS SPF: sender matches SPF record
-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1TwVJm-0002an-B1
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: Sat, 19 Jan 2013 10:06:32 -0000
Matt, I saw your commit and immediately started using it for testing.
Now I think the bitcoinj side needs some love because not one
transaction is being confirmed (all just pending) when replaying the
blockchain.
On 01/18/2013 05:38 PM, Mike Hearn wrote:
> 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
>>
>>
>
> ------------------------------------------------------------------------------
> Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
> much more. Get web development skills now with LearnDevNow -
> 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
> SALE $99.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122812
>
|
