References: <CA+8xBpcfxdpg-z4OQab3379amznM30Ae-Kurko0BKuySwfBy+Q@mail.gmail.com>
	<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 <zgenjix@yahoo.com>
To: "bitcoin-development@lists.sourceforge.net"
	<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
Subject: Re: [Bitcoin-development] BIP 35: add mempool message
Precedence: list
Reply-To: Amir Taaki <zgenjix@yahoo.com>

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 <moon@justmoon.=
de>=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