Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1T2Ldw-0002Vl-9Y for bitcoin-development@lists.sourceforge.net; Fri, 17 Aug 2012 12:27:12 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.175 as permitted sender) client-ip=74.125.82.175; envelope-from=mh.in.england@gmail.com; helo=mail-we0-f175.google.com; Received: from mail-we0-f175.google.com ([74.125.82.175]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1T2Ldu-0007Rr-VP for bitcoin-development@lists.sourceforge.net; Fri, 17 Aug 2012 12:27:12 +0000 Received: by weyr6 with SMTP id r6so2763420wey.34 for ; Fri, 17 Aug 2012 05:27:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.3.1 with SMTP id q1mr2386524wes.38.1345206424847; Fri, 17 Aug 2012 05:27:04 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.216.139.134 with HTTP; Fri, 17 Aug 2012 05:27:04 -0700 (PDT) In-Reply-To: References: <20120816175637.GA13454@vps7135.xlshosting.net> <502D482A.2090609@justmoon.de> <1345150660.5139.YahooMailNeo@web121003.mail.ne1.yahoo.com> Date: Fri, 17 Aug 2012 14:27:04 +0200 X-Google-Sender-Auth: Pt0kS4BvwaNWU-9_DRCuCIuMrmQ Message-ID: From: Mike Hearn To: Jeff Garzik Content-Type: multipart/alternative; boundary=20cf302079f41a452604c77547d4 X-Spam-Score: -1.0 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -0.5 AWL AWL: From: address is in the auto white-list X-Headers-End: 1T2Ldu-0007Rr-VP Cc: Bitcoin Development Subject: Re: [Bitcoin-development] BIP 35: add mempool message X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 12:27:12 -0000 --20cf302079f41a452604c77547d4 Content-Type: text/plain; charset=UTF-8 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 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 > --20cf302079f41a452604c77547d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 content= s. It's already too heavy for mobile clients to download the entire mem= pool contents at startup so I probably wouldn't implement/activate supp= ort for this on the bitcoinj side until bloom filtering is done, and then t= his 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 Garzi= k <jgarzik@exmulti.com> wrote:
On MSG_MEMTX: =C2=A0The current version has a much higher Just Works value.=

On empty "inv": =C2=A0It 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). =C2=A0However, unconditionally returning a<= br> response has little to do with feature probing/discovery. =C2=A0It 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/50122= 263/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--20cf302079f41a452604c77547d4--