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 ) 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 ; 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: References: <20120816175637.GA13454@vps7135.xlshosting.net> Date: Thu, 16 Aug 2012 15:36:25 -0400 Message-ID: From: Alan Reiner To: Jeff Garzik 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 wrote: > On Thu, Aug 16, 2012 at 1:56 PM, Pieter Wuille > 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
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.

>> =A0 =A0An "inv" message is always returned, even if empt= y.
>
> 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= .
=A0The 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 sa= me :)



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).

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.



--e89a8f13ea88b2d16304c76728e7--