References: <CA+8xBpcfxdpg-z4OQab3379amznM30Ae-Kurko0BKuySwfBy+Q@mail.gmail.com>
	<20120816175637.GA13454@vps7135.xlshosting.net>
Message-ID: <1345141255.96175.YahooMailNeo@web121001.mail.ne1.yahoo.com>
Date: Thu, 16 Aug 2012 11:20:55 -0700 (PDT)
From: Amir Taaki <zgenjix@yahoo.com>
To: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
In-Reply-To: <20120816175637.GA13454@vps7135.xlshosting.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Bitcoin-development] BIP 35: add mempool message
Precedence: list
Reply-To: Amir Taaki <zgenjix@yahoo.com>

My thoughts:=0A=0AThe extension is simple. It's only really useful for the =
use-cases listed if the majority of nodes implement it. As I view the propo=
sal, it is perfectly simple and uncomplicated. If it's implemented, then I =
suggest to just increment version and make it part of the protocol.=0A=0AOn=
 the flipside it is another notch in complicating an already diffuse protoc=
ol, but it seems a rather benign offense in that regard compared to other c=
hanges (past and future).=0A=0A=0A=0A----- Original Message -----=0AFrom: P=
ieter Wuille <pieter.wuille@gmail.com>=0ATo: Jeff Garzik <jgarzik@exmulti.c=
om>=0ACc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>=
=0ASent: Thursday, August 16, 2012 6:56 PM=0ASubject: Re: [Bitcoin-developm=
ent] BIP 35: add mempool message=0A=0AOn Thu, Aug 16, 2012 at 01:32:04PM -0=
400, Jeff Garzik wrote:=0A> Consensus was we should do a BIP for all P2P ch=
anges, so here it is...=0A>=A0 feedback requested.=0A> =0A> https://en.bitc=
oin.it/wiki/BIP_0035=0A=0AI like the idea of being able to query the memory=
 pool of a node; the=0Aimplementation is straightforward, which is good. Ma=
ybe effectively using the=0Acommand can be added? I suppose it is interesti=
ng in general for nodes to=0Aget a memory pool refill at startup anyway.=0A=
=0A> 1) Upon receipt of a "mempool" message, the node will respond=0A>=A0 =
=A0 with an "inv" message containing MSG_TX hashes of all the=0A>=A0 =A0 tr=
ansactions in the node's transaction memory pool.=0A> =0A>=A0 =A0 An "inv" =
message is always returned, even if empty.=0A=0AI'm not sure about this las=
t. What is it good for? inv packets can always be=0Asent, even not in respo=
nse to others, so it is not that this gives you an=0Aacknowledgement the me=
mpool is updated?=0A=0A> 3) Feature discovery is enabled by checking two "v=
ersion" message attributes:=0A> =0A>=A0 =A0 a) Protocol version >=3D 60002=
=0A>=A0 =A0 b) NODE_NETWORK bit set in nServices=0A=0AThis seems safe, alth=
ough it forces other full implementations that want to=0Aexpose protocol ve=
rsion 60002 (or later) to also implement this. What do they=0Athink about t=
his?=0A=0AI would like to suggest to allocate an extra service bit for this=
. We still=0Ahave 63 left, and this is a well-defined and useful extra serv=
ice that was=0Anot yet provided by any earlier node. Doing that would also =
mean that=0Amempool-providing survices may be discovered before connecting =
to them, as=0Athe service bits are carried around in addr messages. Any opi=
nions about that?=0A=0A-- =0APieter=0A=0A----------------------------------=
--------------------------------------------=0ALive Security Virtual Confer=
ence=0AExclusive live event will cover all the ways today's security and =
=0Athreat landscape has changed and how IT managers can respond. Discussion=
s =0Awill include endpoint security, mobile security and the latest in malw=
are =0Athreats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/=
=0A_______________________________________________=0ABitcoin-development ma=
iling list=0ABitcoin-development@lists.sourceforge.net=0Ahttps://lists.sour=
ceforge.net/lists/listinfo/bitcoin-development=0A