From: Alan Reiner <etotheipi@gmail•com>
To: Jeff Garzik <jgarzik@exmulti•com>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] BIP 35: add mempool message
Date: Thu, 16 Aug 2012 15:36:25 -0400 [thread overview]
Message-ID: <CALf2ePwuLaCyZjxw-JYhbKmXuM1=QEeov5iLKGX9DCsbte-CnA@mail.gmail.com> (raw)
In-Reply-To: <CA+8xBpc-kSVm__O8MHf6LHJHmFNDR55ZkyUGagdv31f2E_ddBg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1851 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 2440 bytes --]
next prev parent reply other threads:[~2012-08-16 19:36 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-16 17:32 Jeff Garzik
2012-08-16 17:40 ` Amir Taaki
2012-08-16 17:43 ` Jeff Garzik
2012-08-16 17:56 ` Pieter Wuille
2012-08-16 18:04 ` Jeff Garzik
2012-08-16 19:36 ` Alan Reiner [this message]
2012-08-16 18:20 ` Amir Taaki
2012-08-16 19:21 ` Stefan Thomas
2012-08-16 20:57 ` Amir Taaki
2012-08-16 21:05 ` Jeff Garzik
2012-08-17 12:27 ` Mike Hearn
2012-08-17 13:40 ` Pieter Wuille
2012-08-17 16:51 ` Jeff Garzik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALf2ePwuLaCyZjxw-JYhbKmXuM1=QEeov5iLKGX9DCsbte-CnA@mail.gmail.com' \
--to=etotheipi@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=jgarzik@exmulti$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox