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
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <laanwj@gmail.com>) id 1Sfmku-0000NC-BM
for bitcoin-development@lists.sourceforge.net;
Sat, 16 Jun 2012 06:45:08 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.210.47 as permitted sender)
client-ip=209.85.210.47; envelope-from=laanwj@gmail.com;
helo=mail-pz0-f47.google.com;
Received: from mail-pz0-f47.google.com ([209.85.210.47])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128)
(Exim 4.76) id 1Sfmks-0003dW-SS
for bitcoin-development@lists.sourceforge.net;
Sat, 16 Jun 2012 06:45:08 +0000
Received: by dalh21 with SMTP id h21so4818601dal.34
for <bitcoin-development@lists.sourceforge.net>;
Fri, 15 Jun 2012 23:45:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.240.99 with SMTP id vz3mr28270688pbc.60.1339829100810; Fri,
15 Jun 2012 23:45:00 -0700 (PDT)
Received: by 10.143.44.2 with HTTP; Fri, 15 Jun 2012 23:45:00 -0700 (PDT)
In-Reply-To: <1339810493.15660.YahooMailNeo@web121004.mail.ne1.yahoo.com>
References: <CA+8xBpdD31koaVBh1RuDZKH1sygr8z10K=bPz8DepqYOa8i6yg@mail.gmail.com>
<1339810493.15660.YahooMailNeo@web121004.mail.ne1.yahoo.com>
Date: Sat, 16 Jun 2012 08:45:00 +0200
Message-ID: <CA+s+GJCKSrJv4L=4Nj4Hs+j2vfM-oWe5ayD_4NOUJMoXCkm3iA@mail.gmail.com>
From: Wladimir <laanwj@gmail.com>
To: Amir Taaki <zgenjix@yahoo.com>
Content-Type: multipart/alternative; boundary=047d7b3396ad9d132204c291456d
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(laanwj[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-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
X-Headers-End: 1Sfmks-0003dW-SS
Cc: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposed new P2P command and response:
getcmds, cmdlist
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
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: Sat, 16 Jun 2012 06:45:08 -0000
--047d7b3396ad9d132204c291456d
Content-Type: text/plain; charset=UTF-8
As replied on the github issue:
Personally I still think it's better to have a clear standardized "protocol
version", that implies what capabilities are supported, instead of a
capability-based system that explicitly lists them.
Capability-based systems (just look at OpenGL) tend to become horrendously
complex, as you have to take into account all possible combinations of
possible interactions, and constantly check for support of specific
features instead of just comparing a version number.
Sure, it can be necessary to distinguish between different types of nodes,
but there is no need to make it this fine-grained.
Wladimir
On Sat, Jun 16, 2012 at 3:34 AM, Amir Taaki <zgenjix@yahoo.com> wrote:
> Introspection/command discovery is nice, but I would prefer it to be
> immediately done in the first version exchange so no assumptions as to how
> a network is operating need to be made.
>
> I like the idea of a flat list of commands. It might make sense to have
> "meta"-commands that alias to groups of commands. i.e "original" for the
> current core subset up to (and including) "pong". The aliases could exist
> in a text definition file which is held on github or bitcoin.org/
>
>
> ----- Original Message -----
> From: Jeff Garzik <jgarzik@exmulti.com>
> To: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
> Cc:
> Sent: Saturday, June 16, 2012 2:13 AM
> Subject: [Bitcoin-development] Proposed new P2P command and response:
> getcmds, cmdlist
>
> Outside of major features advertised network-wide in nService bits,
> P2P protocol lacks a good method of enumerating minor features or
> extensions. The version number increment is coarse-grained, and is
> not self-documenting. A simple extension which lists supported
> commands is added, as demonstrated in this pull request:
>
> https://github.com/bitcoin/bitcoin/pull/1471
>
> Another option is for verack to return this information at login,
> eliminating the need for a separate command/response.
>
> --
> Jeff Garzik
> exMULTI, Inc.
> jgarzik@exmulti.com
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--047d7b3396ad9d132204c291456d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div>As replied on the github issue:</div><div><br></div><div>Personally I =
still think it's better to have a clear standardized "protocol ver=
sion", that implies what capabilities are supported, instead of a capa=
bility-based system that explicitly lists them.</div>
<div><br></div><div>Capability-based systems=C2=A0(just look at OpenGL)=C2=
=A0tend to become horrendously complex, as you have to take into account al=
l possible combinations of possible interactions, and constantly check for =
support of specific features instead of just comparing a version number.</d=
iv>
<div><br></div><div>Sure, it can be necessary to distinguish between differ=
ent types of nodes, but there is no need to make it this fine-grained.</div=
><div><br></div><div>Wladimir</div><br><div class=3D"gmail_quote">On Sat, J=
un 16, 2012 at 3:34 AM, Amir Taaki <span dir=3D"ltr"><<a href=3D"mailto:=
zgenjix@yahoo.com" target=3D"_blank">zgenjix@yahoo.com</a>></span> wrote=
:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Introspection/command discovery is nice, but=
I would prefer it to be immediately done in the first version exchange so =
no assumptions as to how a network is operating need to be made.<br>
<br>
I like the idea of a flat list of commands. It might make sense to have &qu=
ot;meta"-commands that alias to groups of commands. i.e "original=
" for the current core subset up to (and including) "pong". =
The aliases could exist in a text definition file which is held on github o=
r <a href=3D"http://bitcoin.org/" target=3D"_blank">bitcoin.org/</a><br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
----- Original Message -----<br>
From: Jeff Garzik <<a href=3D"mailto:jgarzik@exmulti.com">jgarzik@exmult=
i.com</a>><br>
To: Bitcoin Development <<a href=3D"mailto:bitcoin-development@lists.sou=
rceforge.net">bitcoin-development@lists.sourceforge.net</a>><br>
Cc:<br>
Sent: Saturday, June 16, 2012 2:13 AM<br>
Subject: [Bitcoin-development] Proposed new P2P command and response: getcm=
ds, cmdlist<br>
<br>
Outside of major features advertised network-wide in nService bits,<br>
P2P protocol lacks a good method of enumerating minor features or<br>
extensions.=C2=A0 The version number increment is coarse-grained, and is<br=
>
not self-documenting.=C2=A0 A simple extension which lists supported<br>
commands is added, as demonstrated in this pull request:<br>
<br>
=C2=A0 =C2=A0 <a href=3D"https://github.com/bitcoin/bitcoin/pull/1471" targ=
et=3D"_blank">https://github.com/bitcoin/bitcoin/pull/1471</a><br>
<br>
Another option is for verack to return this information at login,<br>
eliminating the need for a separate command/response.<br>
<br>
--<br>
Jeff Garzik<br>
exMULTI, Inc.<br>
<a href=3D"mailto:jgarzik@exmulti.com">jgarzik@exmulti.com</a><br>
<br>
---------------------------------------------------------------------------=
---<br>
Live Security Virtual Conference<br>
Exclusive live event will cover all the ways today's security and<br>
threat landscape has changed and how IT managers can respond. Discussions<b=
r>
will include endpoint security, mobile security and the latest in malware<b=
r>
threats. <a href=3D"http://www.accelacomm.com/jaw/sfrnl04242012/114/5012226=
3/" target=3D"_blank">http://www.accelacomm.com/jaw/sfrnl04242012/114/50122=
263/</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br>
<br>
---------------------------------------------------------------------------=
---<br>
Live Security Virtual Conference<br>
Exclusive live event will cover all the ways today's security and<br>
threat landscape has changed and how IT managers can respond. Discussions<b=
r>
will include endpoint security, mobile security and the latest in malware<b=
r>
threats. <a href=3D"http://www.accelacomm.com/jaw/sfrnl04242012/114/5012226=
3/" target=3D"_blank">http://www.accelacomm.com/jaw/sfrnl04242012/114/50122=
263/</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br>
--047d7b3396ad9d132204c291456d--
|
