From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1T278V-0005Gn-OH for bitcoin-development@lists.sourceforge.net; Thu, 16 Aug 2012 20:57:47 +0000 X-ACL-Warn: Received: from nm2-vm3.bullet.mail.ne1.yahoo.com ([98.138.91.132]) by sog-mx-4.v43.ch3.sourceforge.com with smtp (Exim 4.76) id 1T278U-0004PW-KD for bitcoin-development@lists.sourceforge.net; Thu, 16 Aug 2012 20:57:47 +0000 Received: from [98.138.90.56] by nm2.bullet.mail.ne1.yahoo.com with NNFMP; 16 Aug 2012 20:57:41 -0000 Received: from [98.138.88.234] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 16 Aug 2012 20:57:41 -0000 Received: from [127.0.0.1] by omp1034.mail.ne1.yahoo.com with NNFMP; 16 Aug 2012 20:57:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 207106.98045.bm@omp1034.mail.ne1.yahoo.com Received: (qmail 23625 invoked by uid 60001); 16 Aug 2012 20:57:41 -0000 X-YMail-OSG: _auKUzcVM1kD0LN45U4Ik2tkevKjTnVDVvyXwLPC.fVAFqU WYwXp7zi6HgckXC6MfHz9rjNDKBV2LvVa_zykRlsWaAWNR2h8jsTQpBooOof g.UsXBFhofTdgg2cOCFM0l5v7CnyOPSvI3veVx85T4_Puo5uvYXtDXE3IzCq mH60kry9EgFo3hdy_OgzbRugGlkTVep3M2DBCZDdbb8imH3jT9XNSo24WJ1o RFLkZDwCAt5jgOMuOnYcsCI4rsmKEZrbav_CaRW_1RULriihdF.a7bunzKu4 CIkGuFnx0tqQT8mnKSZrnVGybP0lFuR8FtS0iJJfzXdI.VCsyvL50gaxrC6V HYOTwpJDu1yQEVNKGfpMomnmKG1InDAM9x7IGZ5_OZo1v.icsnkzkS1KEnOf oo8rYlQYHbv4wIt_yxN3WDgRKtwjwOXUEhIXOvUqCa5.4R5qwekoF6h.VVf5 ybzAXiqUUIg4hrZQjnLoYWTfZVNVrHFrlyTwcWAAHblXDNiwUQJeewY8jAzW GvBHPJuL.mrTsBH.dJcidTCZ9JJe7u1pXvPUYQvL8K9C.sHQDlAVwQdWJkA2 uj7fuSd3mEZ.USmQt5ClgrqZBxmKMDA-- Received: from [92.20.159.204] by web121003.mail.ne1.yahoo.com via HTTP; Thu, 16 Aug 2012 13:57:40 PDT X-Mailer: YahooMailWebService/0.8.120.356233 References: <20120816175637.GA13454@vps7135.xlshosting.net> <502D482A.2090609@justmoon.de> Message-ID: <1345150660.5139.YahooMailNeo@web121003.mail.ne1.yahoo.com> Date: Thu, 16 Aug 2012 13:57:40 -0700 (PDT) From: Amir Taaki To: "bitcoin-development@lists.sourceforge.net" In-Reply-To: <502D482A.2090609@justmoon.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.1 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [98.138.91.132 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (zgenjix[at]yahoo.com) 0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 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.0 AWL AWL: From: address is in the auto white-list X-Headers-End: 1T278U-0004PW-KD Subject: Re: [Bitcoin-development] BIP 35: add mempool message X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Amir Taaki List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 20:57:47 -0000 MSG_MEMTX solves the issue of not knowing whether a given inv is in respons= e to a "mempool" command or not.=0A=0AI don't buy the argument that always = sending a response "inv" makes things easier because code should always be = able to handle misbehaviour from the remote node (ommiting the "inv"). Howe= ver I would argue that it is good to have it, as it makes designing flows o= f logic much easier (first send this, wait for response, do this, ...).=0A= =0A=0A=0A----- Original Message -----=0AFrom: Stefan Thomas =0ATo: bitcoin-development@lists.sourceforge.net=0ACc: =0ASent: Thursday= , August 16, 2012 8:21 PM=0ASubject: Re: [Bitcoin-development] BIP 35: add = mempool message=0A=0A> This seems safe, although it forces other full imple= mentations that want to=0A> expose protocol version 60002 (or later) to als= o implement this. What do they=0A> think about this?=0A=0ABitcoinJS will im= plement it, it's a useful feature and there is no=0Areason not to support i= t.=0A=0ATwo comments from my end:=0A=0A- This is just a thought, but I woul= dn't mind using a new inv_type for=0Athis, e.g. MSG_MEMTX. I could conceiva= bly see a future where broadcast=0Aand relay txs are stored in a very fast = local cache whereas the general=0Amempool is stored in a slower data struct= ure. By being able to=0Adistinguish incoming getdata requests I can save a = few milliseconds by=0Aquerying the right storage right away. Might also hel= p with things like=0Atelling apart broadcast/relayed transactions from the = response to a=0Amempool request for purposes like DoS scoring etc.=0A=0ANot= a big deal by any means, but I also don't see a downside to it.=0Ainv_type= s are not a scarce resource, we have four billion of them available.=0A=0AF= or now clients would just treat MSG_TX and MSG_MEMTX interchangeably.=0A=0A= - If a node doesn't have anything in it's mempool it sends back an empty=0A= inv message. This is either ambiguous (if other things also send empty=0Ain= v messages in the future) or arbitrary (why should an empty inv be=0Aassoci= ated with a mempool request of all things.) Instead why not=0Arespond with = an inv message that contains a single element of type=0AMSG_MEMTX and hash = 0. That would a very direct way to indicate that this=0Aresponse is associa= ted with a mempool request.=0A=0A=0AI'm not married to either suggestion, j= ust trying to add my perspective.=0AOne thing you notice when reimplementin= g Bitcoin is that Bitcoin's=0Aprotocol leaves out a lot of information not = for space reasons, but=0Abecause the reference client's implementation does= n't happen to need it.=0ASometimes however this locks other clients into do= ing things the same=0Away. If we can make the protocol a bit richer, especi= ally if this=0Adoesn't cost any extra bytes, then we should consider it as = it might=0Ahelp some implementation down the road make a neat optimization.= =0A=0A=0AOn 8/16/2012 7:56 PM, Pieter Wuille wrote:=0A> On Thu, Aug 16, 201= 2 at 01:32:04PM -0400, Jeff Garzik wrote:=0A>> Consensus was we should do a= BIP for all P2P changes, so here it is...=0A>>=A0 feedback requested.=0A>>= =0A>> https://en.bitcoin.it/wiki/BIP_0035=0A> I like the idea of being able= to query the memory pool of a node; the=0A> implementation is straightforw= ard, which is good. Maybe effectively using the=0A> command can be added? I= suppose it is interesting in general for nodes to=0A> get a memory pool re= fill at startup anyway.=0A>=0A>> 1) Upon receipt of a "mempool" message, th= e node will respond=0A>>=A0 =A0 with an "inv" message containing MSG_TX has= hes of all the=0A>>=A0 =A0 transactions in the node's transaction memory po= ol.=0A>>=0A>>=A0 =A0 An "inv" message is always returned, even if empty.=0A= > I'm not sure about this last. What is it good for? inv packets can always= be=0A> sent, even not in response to others, so it is not that this gives = you an=0A> acknowledgement the mempool is updated?=0A>=0A>> 3) Feature disc= overy is enabled by checking two "version" message attributes:=0A>>=0A>>=A0= =A0 a) Protocol version >=3D 60002=0A>>=A0 =A0 b) NODE_NETWORK bit set in = nServices=0A> This seems safe, although it forces other full implementation= s that want to=0A> expose protocol version 60002 (or later) to also impleme= nt this. What do they=0A> think about this?=0A>=0A> I would like to suggest= to allocate an extra service bit for this. We still=0A> have 63 left, and = this is a well-defined and useful extra service that was=0A> not yet provid= ed by any earlier node. Doing that would also mean that=0A> mempool-providi= ng survices may be discovered before connecting to them, as=0A> the service= bits are carried around in addr messages. Any opinions about that?=0A>=0A= =0A=0A---------------------------------------------------------------------= ---------=0ALive Security Virtual Conference=0AExclusive live event will co= ver all the ways today's security and =0Athreat landscape has changed and h= ow IT managers can respond. Discussions =0Awill include endpoint security, = mobile security and the latest in malware =0Athreats. http://www.accelacomm= .com/jaw/sfrnl04242012/114/50122263/=0A____________________________________= ___________=0ABitcoin-development mailing list=0ABitcoin-development@lists.= sourceforge.net=0Ahttps://lists.sourceforge.net/lists/listinfo/bitcoin-deve= lopment=0A