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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <etotheipi@gmail.com>) id 1T25rs-0006Aa-4X
for bitcoin-development@lists.sourceforge.net;
Thu, 16 Aug 2012 19:36:32 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.53 as permitted sender)
client-ip=74.125.82.53; envelope-from=etotheipi@gmail.com;
helo=mail-wg0-f53.google.com;
Received: from mail-wg0-f53.google.com ([74.125.82.53])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1T25rr-0004Pj-BV
for bitcoin-development@lists.sourceforge.net;
Thu, 16 Aug 2012 19:36:32 +0000
Received: by wgbfm10 with SMTP id fm10so2210076wgb.10
for <bitcoin-development@lists.sourceforge.net>;
Thu, 16 Aug 2012 12:36:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.180.109.129 with SMTP id hs1mr5775883wib.0.1345145785208; Thu,
16 Aug 2012 12:36:25 -0700 (PDT)
Received: by 10.194.32.137 with HTTP; Thu, 16 Aug 2012 12:36:25 -0700 (PDT)
In-Reply-To: <CA+8xBpc-kSVm__O8MHf6LHJHmFNDR55ZkyUGagdv31f2E_ddBg@mail.gmail.com>
References: <CA+8xBpcfxdpg-z4OQab3379amznM30Ae-Kurko0BKuySwfBy+Q@mail.gmail.com>
<20120816175637.GA13454@vps7135.xlshosting.net>
<CA+8xBpc-kSVm__O8MHf6LHJHmFNDR55ZkyUGagdv31f2E_ddBg@mail.gmail.com>
Date: Thu, 16 Aug 2012 15:36:25 -0400
Message-ID: <CALf2ePwuLaCyZjxw-JYhbKmXuM1=QEeov5iLKGX9DCsbte-CnA@mail.gmail.com>
From: Alan Reiner <etotheipi@gmail.com>
To: Jeff Garzik <jgarzik@exmulti.com>
Content-Type: multipart/alternative; boundary=e89a8f13ea88b2d16304c76728e7
X-Spam-Score: -0.6 (/)
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
(etotheipi[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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: 1T25rr-0004Pj-BV
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP 35: add mempool message
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: Thu, 16 Aug 2012 19:36:32 -0000
--e89a8f13ea88b2d16304c76728e7
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Aug 16, 2012 at 2:04 PM, Jeff Garzik <jgarzik@exmulti.com> wrote:
> On Thu, Aug 16, 2012 at 1:56 PM, Pieter Wuille <pieter.wuille@gmail.com>
> wrote:
> > I suppose it is interesting in general for nodes to
> > get a memory pool refill at startup anyway.
>
> Yes.
>
> >> An "inv" message is always returned, even if empty.
> >
> > I'm not sure about this last. What is it good for? inv packets can
> always be
> > sent, even not in response to others, so it is not that this gives you an
> > acknowledgement the mempool is updated?
>
> A simple guarantee of 1:1 correspondence between request and response.
> The bitcoin protocol sometimes simply elides a response when the
> response would be empty, and this makes it difficult to know whether a
> request is timing out or already processed.
>
> Sending a ping(nonce) after each P2P command is another way of achieving
> same :)
>
>
Is there a problem with sending unrecognized messages to nodes? If we
create a new message type specifically asking for memory pool transactions,
and we broadcast it to all nodes that we are connected to, and none of them
respond, then either there are no tx in their memory pools, or they don't
recognize the message and ignore it. Either way, you're not going to get
any extra information out of them. If you really care, a simple ping can
identify whether they're still connected and should've responded (as Jeff
said).
As long as the older node won't cut you off for sending one unrecognized
request, it seems that you can get by fine without requiring that bit. I
guess it depends on the utility of definitively identifying whether a node
supports the functionality. I personally don't feel like it's critical,
especially considering that this is most useful only during the transient
period when it's not normal for nodes to support it yet.
--e89a8f13ea88b2d16304c76728e7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div class=3D"gmail_quote">On Thu, Aug 16, 2012 at 2:04 PM, Jeff Garzik <sp=
an dir=3D"ltr"><<a href=3D"mailto:jgarzik@exmulti.com" target=3D"_blank"=
>jgarzik@exmulti.com</a>></span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">
<div class=3D"im">On Thu, Aug 16, 2012 at 1:56 PM, Pieter Wuille <<a hre=
f=3D"mailto:pieter.wuille@gmail.com">pieter.wuille@gmail.com</a>> wrote:=
<br>
> I suppose it is interesting in general for nodes to<br>
> get a memory pool refill at startup anyway.<br>
<br>
</div>Yes.<br>
<div class=3D"im"><br>
>> =A0 =A0An "inv" message is always returned, even if empt=
y.<br>
><br>
> I'm not sure about this last. What is it good for? inv packets can=
always be<br>
> sent, even not in response to others, so it is not that this gives you=
an<br>
> acknowledgement the mempool is updated?<br>
<br>
</div>A simple guarantee of 1:1 correspondence between request and response=
.<br>
=A0The bitcoin protocol sometimes simply elides a response when the<br>
response would be empty, and this makes it difficult to know whether a<br>
request is timing out or already processed.<br>
<br>
Sending a ping(nonce) after each P2P command is another way of achieving sa=
me :)<br>
<div class=3D"im"><br></div></blockquote><div><br></div><div><br></div><div=
>Is there a problem with sending unrecognized messages to nodes? =A0 If we =
create a new message type specifically asking for memory pool transactions,=
and we broadcast it to all nodes that we are connected to, and none of the=
m respond, then either there are no tx in their memory pools, or they don&#=
39;t recognize the message and ignore it. =A0Either way, you're not goi=
ng to get any extra information out of them. =A0If you really care, a simpl=
e ping can identify whether they're still connected and should've r=
esponded (as Jeff said).</div>
<div><br></div><div>As long as the older node won't cut you off for sen=
ding one unrecognized request, it seems that you can get by fine without re=
quiring that bit. =A0I guess it depends on the utility of definitively iden=
tifying whether a node supports the functionality. =A0I personally don'=
t feel like it's critical, especially considering that this is most use=
ful only during the transient period when it's not normal for nodes to =
support it yet.</div>
<div><br></div><div><br></div><div><br></div></div>
--e89a8f13ea88b2d16304c76728e7--
|
