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 <zgenjix@yahoo.com>) 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: <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
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 <zgenjix@yahoo.com>
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <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