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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <zgenjix@yahoo.com>) id 1T24gn-0007Pf-RV
for bitcoin-development@lists.sourceforge.net;
Thu, 16 Aug 2012 18:21:01 +0000
X-ACL-Warn:
Received: from nm5-vm0.bullet.mail.ne1.yahoo.com ([98.138.90.251])
by sog-mx-1.v43.ch3.sourceforge.com with smtp (Exim 4.76)
id 1T24gm-0000WD-W8 for bitcoin-development@lists.sourceforge.net;
Thu, 16 Aug 2012 18:21:01 +0000
Received: from [98.138.90.48] by nm5.bullet.mail.ne1.yahoo.com with NNFMP;
16 Aug 2012 18:20:55 -0000
Received: from [98.138.86.156] by tm1.bullet.mail.ne1.yahoo.com with NNFMP;
16 Aug 2012 18:20:55 -0000
Received: from [127.0.0.1] by omp1014.mail.ne1.yahoo.com with NNFMP;
16 Aug 2012 18:20:55 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 630626.82249.bm@omp1014.mail.ne1.yahoo.com
Received: (qmail 12576 invoked by uid 60001); 16 Aug 2012 18:20:55 -0000
X-YMail-OSG: cSKX2KgVM1nIVDCXrMr4.LyfqIMDXAXsCWWwAYE1aEJr1QR
p75yh_uHKTj2bQxNmDaslVXlj75t5tEBRt24nK2QMFeELWzFndBq7YiutOPd
wWMDGcfToIzck2yg.JFxFHOKvo8kRfONayOeanuJWNNjzzC29LSeDgms_adw
sVY2LJtvSEdcDsVAtRc1yDajjkdctDBoJwayREDBwhXa.McbSsKj9ADpah65
QEgtRUyzf0lRbdTGIjgB5ZhBLsgarxTjBwC59M.1IciokM.9XDIL91a6jHXK
JOEdyfP6N9F_7fRl70MeIUzAP4P9Jg4bzJvsbJvV7haZH8iGARNecE_hfxN1
E0xMdGfQZc8wxqBe2WMXdibz.kF1VIRZnd6dMhvNpXnWtjFB.cjmFouAPzO1
3Dkx0iWex9hz2RUVU4bWG4lUtGLxV2ikGGn4krgRbZbU0_MFA7ShSDiZ0sLg
TwJKHr_52oZAn0qXc6jmxWbFW_rI1ifqWgLR5C31Zp0UiU7vLOBGXhgy2D0m
AKJVUidyabbHaMES.B3oMY6eGECdTlpLTfSlV8kAwXUSXHUfnt0XU.gqJwYn
5HUoeba_rjKgZsiP7tsj3GmQT52rLHA--
Received: from [92.20.159.204] by web121001.mail.ne1.yahoo.com via HTTP;
Thu, 16 Aug 2012 11:20:55 PDT
X-Mailer: YahooMailWebService/0.8.120.356233
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
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.90.251 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: 1T24gm-0000WD-W8
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 18:21:01 -0000
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
|
