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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1TR6Lw-0006FG-Ng
for bitcoin-development@lists.sourceforge.net;
Wed, 24 Oct 2012 19:10:56 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.53 as permitted sender)
client-ip=74.125.82.53; envelope-from=mh.in.england@gmail.com;
helo=mail-wg0-f53.google.com;
Received: from mail-wg0-f53.google.com ([74.125.82.53])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1TR6Lv-0001VE-Qd
for bitcoin-development@lists.sourceforge.net;
Wed, 24 Oct 2012 19:10:56 +0000
Received: by mail-wg0-f53.google.com with SMTP id dr1so540378wgb.10
for <bitcoin-development@lists.sourceforge.net>;
Wed, 24 Oct 2012 12:10:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.180.90.201 with SMTP id by9mr4659801wib.5.1351105849719; Wed,
24 Oct 2012 12:10:49 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.216.236.30 with HTTP; Wed, 24 Oct 2012 12:10:49 -0700 (PDT)
Received: by 10.216.236.30 with HTTP; Wed, 24 Oct 2012 12:10:49 -0700 (PDT)
In-Reply-To: <CABsx9T0JyFJKLWK09NEzDk6B9Z2Yz7T55kf8GJ2o3ViCnBpRAw@mail.gmail.com>
References: <CANEZrP0XALwBFJyZTzYd5xBp4MRrjv0s_y2tOXbO7UgjWF2HzA@mail.gmail.com>
<20121024162255.GA30290@vps7135.xlshosting.net>
<CANEZrP1sxtOb+czMtBTkmzngEwMYRqD667WyKQkAOKLi+mGBGQ@mail.gmail.com>
<20121024171104.GA31766@vps7135.xlshosting.net>
<CABsx9T0JyFJKLWK09NEzDk6B9Z2Yz7T55kf8GJ2o3ViCnBpRAw@mail.gmail.com>
Date: Wed, 24 Oct 2012 21:10:49 +0200
X-Google-Sender-Auth: 58S35qqLFmBUIL8Q5hyu-wfs0DU
Message-ID: <CANEZrP1AFL6ZbV7Njr1s8ggsZkQA1dv_3LYT3z+y83UKqn7Kgg@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=f46d0438eba939fac504ccd2d875
X-Spam-Score: -0.9 (/)
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
-0.4 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1TR6Lv-0001VE-Qd
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, 24 Oct 2012 19:10:56 -0000
--f46d0438eba939fac504ccd2d875
Content-Type: text/plain; charset=UTF-8
Bitcoin already keeps track of which nodes have seen what to avoid
redundant inv announcements.
I think if you are approaching most transactions in a block matching the
filter then you would just request full blocks and do all the filtering
client side
On Oct 24, 2012 8:54 PM, "Gavin Andresen" <gavinandresen@gmail.com> wrote:
> RE: sharing parts of the merkle branches when returning a 'merkleblock' :
>
> I think I agree that complicating the BIP for what should be a very
> rare case (more than a handful of transactions in a block match the
> transactions in your wallet) is the right decision.
>
> I want to make sure I'm understanding this bit correctly:
>
> "In addition, because a merkleblock message contains only a list of
> transaction hashes, any transactions that the requesting node hasn't
> either received or announced with an inv will be automatically sent as
> well. This avoids a slow roundtrip that would otherwise be required
> (receive hashes, didn't see some of these transactions yet, ask for
> them)."
>
> Requiring serving/relaying nodes to keep track of which transactions
> they have or have not sent to their peers makes me nervous. I think
> requiring an extra 'inv' round-trip would be simpler to implement and
> less likely to lead to some kind of DoS attack.
>
> --
> --
> Gavin Andresen
>
--f46d0438eba939fac504ccd2d875
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p>Bitcoin already keeps track of which nodes have seen what to avoid redun=
dant inv announcements. </p>
<p>I think if you are approaching most transactions in a block matching the=
filter then you would just request full blocks and do all the filtering cl=
ient side </p>
<div class=3D"gmail_quote">On Oct 24, 2012 8:54 PM, "Gavin Andresen&qu=
ot; <<a href=3D"mailto:gavinandresen@gmail.com">gavinandresen@gmail.com<=
/a>> wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
RE: sharing parts of the merkle branches when returning a 'merkleblock&=
#39; :<br>
<br>
I think I agree that complicating the BIP for what should be a very<br>
rare case (more than a handful of transactions in a block match the<br>
transactions in your wallet) is the right decision.<br>
<br>
I want to make sure I'm understanding this bit correctly:<br>
<br>
"In addition, because a merkleblock message contains only a list of<br=
>
transaction hashes, any transactions that the requesting node hasn't<br=
>
either received or announced with an inv will be automatically sent as<br>
well. This avoids a slow roundtrip that would otherwise be required<br>
(receive hashes, didn't see some of these transactions yet, ask for<br>
them)."<br>
<br>
Requiring serving/relaying nodes to keep track of which transactions<br>
they have or have not sent to their peers makes me nervous. I think<br>
requiring an extra 'inv' round-trip would be simpler to implement a=
nd<br>
less likely to lead to some kind of DoS attack.<br>
<br>
--<br>
--<br>
Gavin Andresen<br>
</blockquote></div>
--f46d0438eba939fac504ccd2d875--
|
