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
|
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 1SfoaS-0003KF-3O
for bitcoin-development@lists.sourceforge.net;
Sat, 16 Jun 2012 08:42:28 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.160.47 as permitted sender)
client-ip=209.85.160.47; envelope-from=laanwj@gmail.com;
helo=mail-pb0-f47.google.com;
Received: from mail-pb0-f47.google.com ([209.85.160.47])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128)
(Exim 4.76) id 1SfoaR-00070D-Ay
for bitcoin-development@lists.sourceforge.net;
Sat, 16 Jun 2012 08:42:28 +0000
Received: by pbbrq2 with SMTP id rq2so5841037pbb.34
for <bitcoin-development@lists.sourceforge.net>;
Sat, 16 Jun 2012 01:42:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.241.232 with SMTP id wl8mr28482826pbc.106.1339836141291;
Sat, 16 Jun 2012 01:42:21 -0700 (PDT)
Received: by 10.143.44.2 with HTTP; Sat, 16 Jun 2012 01:42:21 -0700 (PDT)
In-Reply-To: <201206160916.24485.andyparkins@gmail.com>
References: <CA+8xBpdD31koaVBh1RuDZKH1sygr8z10K=bPz8DepqYOa8i6yg@mail.gmail.com>
<1339810493.15660.YahooMailNeo@web121004.mail.ne1.yahoo.com>
<CA+s+GJCKSrJv4L=4Nj4Hs+j2vfM-oWe5ayD_4NOUJMoXCkm3iA@mail.gmail.com>
<201206160916.24485.andyparkins@gmail.com>
Date: Sat, 16 Jun 2012 10:42:21 +0200
Message-ID: <CA+s+GJA2-+HuRFfX3b=-4wv7u9iFCnfOMyDKwekxmipszt27Cw@mail.gmail.com>
From: Wladimir <laanwj@gmail.com>
To: Andy Parkins <andyparkins@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b339bf5424a3b04c292e9b8
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: 1SfoaR-00070D-Ay
Cc: 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 08:42:28 -0000
--047d7b339bf5424a3b04c292e9b8
Content-Type: text/plain; charset=UTF-8
On Sat, Jun 16, 2012 at 10:16 AM, Andy Parkins <andyparkins@gmail.com>wrote:
>
> It's less of a problem in a (nearly) stateless protocol like Bitcoin.
>
It's currently (nearly) stateless, however it would be short-sighted to
think it will stay that way. State is being introduced as we speak; for
example, connection-specific filters.
I like the idea of a capabilities command; as time goes on and the ecosystem
> of thin/spv/semi-thin/headers-only/blocks-on-demand/reverse-search-
> blockchain/memory-pool-query clients becomes more varied, it's going to be
> more an more important. The particular example that occurs is thin clients
> connecting to the network are going to want to ensure they are connected to
> at least one non-thin client.
>
Which is a perfectly reasonable requirement. However, one could simply
standardize what a 'thin client' and what a 'thick client' does and offers
(at a certain version level), without having to explicitly enumerate
everything over the protocol.
This also makes it easier to deprecate (lack of) certain features later on.
You can simply drop support for protocol versions before a certain number
(which has happened before). With the extension system this is much harder,
which likely means you keep certain workarounds forever.
Letting the node know of each others capabilities at connection time helps
somewhat. It'd allow refusing clients that do not implement a certain
feature. Then again, to me it's unclear what this wins compared to
incremental protocol versions with clear requirements.
I'm just afraid that the currently simple P2P protocol will turn into a zoo
of complicated (and potentially buggy/insecure) interactions.
So maybe a capability system is a good idea but then the granularity should
be large, not command-level. The interaction between protocol versions and
capabilities needs to be defined as well. Does offering "getdata" at
protocol version 10 mean the same as offering it at protocol version 11"?
Probably not guaranteed. The arguments might have changed. So it's not
entirely self-documenting either.
Wladimir
--047d7b339bf5424a3b04c292e9b8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sat, Jun 16, 2012 at 10:16 AM, Andy Parkins <span dir=3D"ltr"><<a hre=
f=3D"mailto:andyparkins@gmail.com" target=3D"_blank">andyparkins@gmail.com<=
/a>></span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">
<div><br>
</div>It's less of a problem in a (nearly) stateless protocol like Bitc=
oin.<br></blockquote><div><br></div><div>It's currently (nearly) statel=
ess, however it would be short-sighted to think it will stay that way. Stat=
e is being introduced as we speak; for example, connection-specific filters=
.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">I like the idea of a capabili=
ties command; as time goes on and the ecosystem<br>
of thin/spv/semi-thin/headers-only/blocks-on-demand/reverse-search-<br>
blockchain/memory-pool-query clients becomes more varied, it's going to=
be<br>
more an more important. =C2=A0The particular example that occurs is thin cl=
ients<br>
connecting to the network are going to want to ensure they are connected to=
<br>
at least one non-thin client.<br></blockquote><div><br></div><div>Which is =
a perfectly reasonable requirement. However, one could simply standardize w=
hat a 'thin client' and what a 'thick client' does and offe=
rs (at a certain version level), without having to explicitly enumerate eve=
rything over the protocol.=C2=A0</div>
<div><br></div><div>This also makes it easier to deprecate (lack of) certai=
n features later on. You can simply drop support for protocol versions befo=
re a certain number (which has happened before). With the extension system =
this is much harder, which likely means you keep certain workarounds foreve=
r.=C2=A0</div>
<div><br></div><div>Letting the node know of each others capabilities at co=
nnection time helps somewhat. It'd allow refusing clients that do not i=
mplement a certain feature. Then again, to me it's unclear what this wi=
ns compared to incremental protocol versions with clear requirements.=C2=A0=
</div>
<div><br></div><div>I'm just afraid that the currently simple P2P proto=
col will turn into a zoo of complicated (and potentially buggy/insecure) in=
teractions.=C2=A0</div><div><br></div><div>So maybe a capability system is =
a good idea but then the granularity should be large, not command-level. Th=
e interaction between protocol versions and capabilities needs to be define=
d as well. Does offering "getdata" at protocol version 10 mean th=
e same as offering it at protocol version 11"? Probably not guaranteed=
. The arguments might have changed. So it's not entirely self-documenti=
ng either.</div>
<div><br></div><div>Wladimir</div><div><br></div></div>
--047d7b339bf5424a3b04c292e9b8--
|
