📅 Original date posted:2012-08-16
📝 Original message: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 :)
> This seems safe, although it forces other full implementations that want to
> expose protocol version 60002 (or later) to also implement this. What do they
> think about this?
>
> I would like to suggest to allocate an extra service bit for this. We still
> have 63 left, and this is a well-defined and useful extra service that was
> not yet provided by any earlier node. Doing that would also mean that
> mempool-providing survices may be discovered before connecting to them, as
> the service bits are carried around in addr messages. Any opinions about that?
An nServices bit would be a better fit for this optional service, but
nServices bits seemed like a scarce resource, so I elected to be
conservative.
Absent the scarce-resource concern, I'd vote for an nServices bit.
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com
Jeff Garzik [ARCHIVE] /
npub1kf…f3f58
2023-06-07 10:29:12
in reply to nevent1q…wk25
Author Public Key
npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58Published at
2023-06-07 10:29:12Event JSON
{
"id": "908f5bdaca01b012f39020c9b6f1393b28e372dd169e1fb33ddcc47fce667349",
"pubkey": "b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11",
"created_at": 1686133752,
"kind": 1,
"tags": [
[
"e",
"230151bb9ac0f5af1d29fc832b378f46a6a5a710d215c859a985fc5e0d75bc92",
"",
"root"
],
[
"e",
"2551188b5a90c93bddf563c1d55b77bff9ed4ddd98c341200eabd40003146087",
"",
"reply"
],
[
"p",
"b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11"
]
],
"content": "📅 Original date posted:2012-08-16\n📝 Original message:On Thu, Aug 16, 2012 at 1:56 PM, Pieter Wuille \u003cpieter.wuille at gmail.com\u003e wrote:\n\u003e I suppose it is interesting in general for nodes to\n\u003e get a memory pool refill at startup anyway.\n\nYes.\n\n\u003e\u003e An \"inv\" message is always returned, even if empty.\n\u003e\n\u003e I'm not sure about this last. What is it good for? inv packets can always be\n\u003e sent, even not in response to others, so it is not that this gives you an\n\u003e acknowledgement the mempool is updated?\n\nA simple guarantee of 1:1 correspondence between request and response.\n The bitcoin protocol sometimes simply elides a response when the\nresponse would be empty, and this makes it difficult to know whether a\nrequest is timing out or already processed.\n\nSending a ping(nonce) after each P2P command is another way of achieving same :)\n\n\u003e This seems safe, although it forces other full implementations that want to\n\u003e expose protocol version 60002 (or later) to also implement this. What do they\n\u003e think about this?\n\u003e\n\u003e I would like to suggest to allocate an extra service bit for this. We still\n\u003e have 63 left, and this is a well-defined and useful extra service that was\n\u003e not yet provided by any earlier node. Doing that would also mean that\n\u003e mempool-providing survices may be discovered before connecting to them, as\n\u003e the service bits are carried around in addr messages. Any opinions about that?\n\nAn nServices bit would be a better fit for this optional service, but\nnServices bits seemed like a scarce resource, so I elected to be\nconservative.\n\nAbsent the scarce-resource concern, I'd vote for an nServices bit.\n\n-- \nJeff Garzik\nexMULTI, Inc.\njgarzik at exmulti.com",
"sig": "84844b7c86f30036b3918e57409cc271a5839b5d9fda5fc7996ae9a99a17ed42cfe69ff738a93fd18659755dd88582a3fdc5595b139962370075de42b284df09"
}