Pieter Wuille [ARCHIVE] on Nostr: 📅 Original date posted:2012-08-17 📝 Original message:On Thu, Aug 16, 2012 at ...

📅 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