References: <CA+8xBpcfxdpg-z4OQab3379amznM30Ae-Kurko0BKuySwfBy+Q@mail.gmail.com>
Message-ID: <1345138853.81509.YahooMailNeo@web121006.mail.ne1.yahoo.com>
Date: Thu, 16 Aug 2012 10:40:53 -0700 (PDT)
From: Amir Taaki <zgenjix@yahoo.com>
To: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
In-Reply-To: <CA+8xBpcfxdpg-z4OQab3379amznM30Ae-Kurko0BKuySwfBy+Q@mail.gmail.com>
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>

The format for "mempool" packet is missing. I'm guessing that it is an empt=
y message, right?=0A=0AMight be good to add that.=0A=0A=0A=0A----- Original=
 Message -----=0AFrom: Jeff Garzik <jgarzik@exmulti.com>=0ATo: Bitcoin Deve=
lopment <bitcoin-development@lists.sourceforge.net>=0ACc: =0ASent: Thursday=
, August 16, 2012 6:32 PM=0ASubject: [Bitcoin-development] BIP 35: add memp=
ool message=0A=0AConsensus was we should do a BIP for all P2P changes, so h=
ere it is...=0Afeedback requested.=0A=0Ahttps://en.bitcoin.it/wiki/BIP_0035=
=0A=0AAbstract=0A-------------------------------------------=0AMake a netwo=
rk node's transaction memory pool accessible via a new=0A"mempool" message.=
=A0 Extend the existing "getdata" message behavior to permit=0Aaccessing th=
e transaction memory pool.=0A=0A=0AMotivation=0A---------------------------=
----------------=0ASeveral use cases make it desireable to expore a network=
 node's transaction=0Amemory pool:=0A* SPV clients, wishing to obtain zero-=
confirmation transactions sent or=0A=A0 received.=0A* Miners, downloading e=
xisting network transactions after a restart.=0A* Remote network diagnostic=
s.=0A=0A=0ASpecification=0A-------------------------------------------=0A1)=
 Upon receipt of a "mempool" message, the node will respond=0A=A0  with an =
"inv" message containing MSG_TX hashes of all the=0A=A0  transactions in th=
e node's transaction memory pool.=0A=0A=A0  An "inv" message is always retu=
rned, even if empty.=0A=0A2) The typical node behavior in response to an "i=
nv" is "getdata".=0A=0A=A0  However, the reference Satoshi implementation i=
gnores requests=0A=A0  for transaction hashes outside that which is recentl=
y relayed.=0A=0A=A0  To support "mempool", an implementation must extend it=
s "getdata"=0A=A0  message support to querying the memory pool.=0A=0A3) Fea=
ture discovery is enabled by checking two "version" message attributes:=0A=
=0A=A0  a) Protocol version >=3D 60002=0A=A0  b) NODE_NETWORK bit set in nS=
ervices=0A=0A=0ABackwards compatibility=0A---------------------------------=
----------=0AOlder clients remain 100% compatible and interoperable after t=
his change.=0A=0A=0AImplementation=0A--------------------------------------=
-----=0ASee https://github.com/bitcoin/bitcoin/pull/1641=0A=0A-- =0AJeff Ga=
rzik=0AexMULTI, Inc.=0Ajgarzik@exmulti.com=0A=0A---------------------------=
---------------------------------------------------=0ALive Security Virtual=
 Conference=0AExclusive live event will cover all the ways today's security=
 and =0Athreat landscape has changed and how IT managers can respond. Discu=
ssions =0Awill include endpoint security, mobile security and the latest in=
 malware =0Athreats. http://www.accelacomm.com/jaw/sfrnl04242012/114/501222=
63/=0A_______________________________________________=0ABitcoin-development=
 mailing list=0ABitcoin-development@lists.sourceforge.net=0Ahttps://lists.s=
ourceforge.net/lists/listinfo/bitcoin-development=0A