Date: Fri, 17 Aug 2012 15:40:01 +0200
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Jeff Garzik <jgarzik@exmulti.com>
Message-ID: <20120817134000.GA30465@vps7135.xlshosting.net>
References: <CA+8xBpcfxdpg-z4OQab3379amznM30Ae-Kurko0BKuySwfBy+Q@mail.gmail.com>
	<20120816175637.GA13454@vps7135.xlshosting.net>
	<502D482A.2090609@justmoon.de>
	<1345150660.5139.YahooMailNeo@web121003.mail.ne1.yahoo.com>
	<CA+8xBpd4uHO63QCFtOqLB6SPLYO_9y2fQGbNLFH81ovGukhBmg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+8xBpd4uHO63QCFtOqLB6SPLYO_9y2fQGbNLFH81ovGukhBmg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP 35: add mempool message
Precedence: list

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