📅 Original date posted:2012-08-16
📝 Original message:On Thu, Aug 16, 2012 at 2:04 PM, Jeff Garzik <jgarzik at exmulti.com> wrote:
> On Thu, Aug 16, 2012 at 1:56 PM, Pieter Wuille <pieter.wuille at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120816/adc8bbd9/attachment.html>;
Alan Reiner [ARCHIVE] /
npub1sm…mnq7h
2023-06-07 10:29:15
in reply to nevent1q…9vzd
Author Public Key
npub1sm6zhjmk5scuz294jmpkw99wwwjzetjgwp4fu4gn6utqgdz87hkqamnq7hPublished at
2023-06-07 10:29:15Event JSON
{
"id": "29233c066b005a0e59c27803661d925d3025c5ae1af2c0cc20abd805c05dbfa8",
"pubkey": "86f42bcb76a431c128b596c36714ae73a42cae48706a9e5513d716043447f5ec",
"created_at": 1686133755,
"kind": 1,
"tags": [
[
"e",
"230151bb9ac0f5af1d29fc832b378f46a6a5a710d215c859a985fc5e0d75bc92",
"",
"root"
],
[
"e",
"908f5bdaca01b012f39020c9b6f1393b28e372dd169e1fb33ddcc47fce667349",
"",
"reply"
],
[
"p",
"b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11"
]
],
"content": "📅 Original date posted:2012-08-16\n📝 Original message:On Thu, Aug 16, 2012 at 2:04 PM, Jeff Garzik \u003cjgarzik at exmulti.com\u003e wrote:\n\n\u003e On Thu, Aug 16, 2012 at 1:56 PM, Pieter Wuille \u003cpieter.wuille at gmail.com\u003e\n\u003e wrote:\n\u003e \u003e I suppose it is interesting in general for nodes to\n\u003e \u003e get a memory pool refill at startup anyway.\n\u003e\n\u003e Yes.\n\u003e\n\u003e \u003e\u003e An \"inv\" message is always returned, even if empty.\n\u003e \u003e\n\u003e \u003e I'm not sure about this last. What is it good for? inv packets can\n\u003e always be\n\u003e \u003e sent, even not in response to others, so it is not that this gives you an\n\u003e \u003e acknowledgement the mempool is updated?\n\u003e\n\u003e A simple guarantee of 1:1 correspondence between request and response.\n\u003e The bitcoin protocol sometimes simply elides a response when the\n\u003e response would be empty, and this makes it difficult to know whether a\n\u003e request is timing out or already processed.\n\u003e\n\u003e Sending a ping(nonce) after each P2P command is another way of achieving\n\u003e same :)\n\u003e\n\u003e\n\nIs there a problem with sending unrecognized messages to nodes? If we\ncreate a new message type specifically asking for memory pool transactions,\nand we broadcast it to all nodes that we are connected to, and none of them\nrespond, then either there are no tx in their memory pools, or they don't\nrecognize the message and ignore it. Either way, you're not going to get\nany extra information out of them. If you really care, a simple ping can\nidentify whether they're still connected and should've responded (as Jeff\nsaid).\n\nAs long as the older node won't cut you off for sending one unrecognized\nrequest, it seems that you can get by fine without requiring that bit. I\nguess it depends on the utility of definitively identifying whether a node\nsupports the functionality. I personally don't feel like it's critical,\nespecially considering that this is most useful only during the transient\nperiod when it's not normal for nodes to support it yet.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120816/adc8bbd9/attachment.html\u003e",
"sig": "b6231f7f09db2be151fd33f7d9e206460d27aa349ec2ee8d3e3fa158ac65aa747905bebf07a2dc79754d39c71959be1845adb697652df71c43764ee13935b8c5"
}