I think MSG_TX is fine. Simply sending an inv to the other node at startup would work, but it's better to request it explicitly as it will let the connecting peer configure a bloom filter before requesting mempool contents. It's already too heavy for mobile clients to download the entire mempool contents at startup so I probably wouldn't implement/activate support for this on the bitcoinj side until bloom filtering is done, and then this BIP would have to be updated to reflect that the response from mempool is filtered.

On Thu, Aug 16, 2012 at 11:05 PM, Jeff Garzik <jgarzik@exmulti.com> 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.

--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti.com

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development