📅 Original date posted:2012-08-17
📝 Original message:On Thu, Aug 16, 2012 at 05:05:58PM -0400, Jeff Garzik wrote:
> On MSG_MEMTX: The current version has a much higher Just Works value.
>
> On empty "inv": It is generally better to do something
> unconditionally, than have a response generated only under certain
> conditions.
>
> And Alan is correct to note that unknown messages are ignored
> (intentionally, for expansion). However, unconditionally returning a
> response has little to do with feature probing/discovery. It is
> simply a clear, deterministic indication that processing is complete,
> for each invocation.
I disagree. Returning an empty "inv" is a very strange way of replying
"empty mempool". Bitcoin P2P is not a request-response protocol, and
"inv" messages are sent where there are inventory items to send. The
reaction to a request (for example "getblocks") can be nothing, or one
or more "inv" messages if necessary. Special casing an empty "inv" to
mean empty mempool is trying to hack a request-response system on top
of the asynchronous system.
If there is need for confirming the transmission of the mempool is
complete, the proposal to use a MSG_MEMTX sounds good to me. No client
will ever receive such an inv without requesting the mempool, and
implementing handling MSG_MEMTX is trivial.
--
Pieter
Pieter Wuille [ARCHIVE] /
npub1tj…jtl6r
2023-06-07 10:29:06
in reply to nevent1q…gc99
Author Public Key
npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6rSeen on
wss://relay.nostr.bandPublished at
2023-06-07 10:29:06Event JSON
{
"id": "b3e2900d68de160bd84db5a5169b1b1c1a4e181683ddd02146f2ea11b776fd79",
"pubkey": "5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6",
"created_at": 1686133746,
"kind": 1,
"tags": [
[
"e",
"230151bb9ac0f5af1d29fc832b378f46a6a5a710d215c859a985fc5e0d75bc92",
"",
"root"
],
[
"e",
"fe7e6eec4ccaca15a8bba2a3f71f6e9bc08cbfbfa4094a13cceae5a9f7e17017",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2012-08-17\n📝 Original message:On Thu, Aug 16, 2012 at 05:05:58PM -0400, Jeff Garzik wrote:\n\u003e On MSG_MEMTX: The current version has a much higher Just Works value.\n\u003e \n\u003e On empty \"inv\": It is generally better to do something\n\u003e unconditionally, than have a response generated only under certain\n\u003e conditions.\n\u003e \n\u003e And Alan is correct to note that unknown messages are ignored\n\u003e (intentionally, for expansion). However, unconditionally returning a\n\u003e response has little to do with feature probing/discovery. It is\n\u003e simply a clear, deterministic indication that processing is complete,\n\u003e for each invocation.\n\nI disagree. Returning an empty \"inv\" is a very strange way of replying\n\"empty mempool\". Bitcoin P2P is not a request-response protocol, and\n\"inv\" messages are sent where there are inventory items to send. The\nreaction to a request (for example \"getblocks\") can be nothing, or one\nor more \"inv\" messages if necessary. Special casing an empty \"inv\" to\nmean empty mempool is trying to hack a request-response system on top\nof the asynchronous system.\n\nIf there is need for confirming the transmission of the mempool is\ncomplete, the proposal to use a MSG_MEMTX sounds good to me. No client\nwill ever receive such an inv without requesting the mempool, and\nimplementing handling MSG_MEMTX is trivial.\n\n-- \nPieter",
"sig": "31d732497a1aa60d92052b9a9f7efdc23b36c8bef3e86c60951ed22919ffbab12900896dcd8912bfcf585ef9eca6c3f9ec55a20acf09f101e4c65b2b79a7c5f2"
}