1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
|
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
|
