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-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <andyparkins@gmail.com>) id 1Sfpi3-0002ht-1M
for bitcoin-development@lists.sourceforge.net;
Sat, 16 Jun 2012 09:54:23 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.175 as permitted sender)
client-ip=74.125.82.175; envelope-from=andyparkins@gmail.com;
helo=mail-we0-f175.google.com;
Received: from mail-we0-f175.google.com ([74.125.82.175])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Sfpi2-0000ao-9h
for bitcoin-development@lists.sourceforge.net;
Sat, 16 Jun 2012 09:54:23 +0000
Received: by werg55 with SMTP id g55so2957867wer.34
for <bitcoin-development@lists.sourceforge.net>;
Sat, 16 Jun 2012 02:54:16 -0700 (PDT)
Received: by 10.216.145.153 with SMTP id p25mr4825279wej.112.1339840456051;
Sat, 16 Jun 2012 02:54:16 -0700 (PDT)
Received: from grissom.localnet ([91.84.15.31])
by mx.google.com with ESMTPS id d10sm16337658wiy.3.2012.06.16.02.54.14
(version=TLSv1/SSLv3 cipher=OTHER);
Sat, 16 Jun 2012 02:54:15 -0700 (PDT)
From: Andy Parkins <andyparkins@gmail.com>
To: Wladimir <laanwj@gmail.com>
Date: Sat, 16 Jun 2012 10:54:11 +0100
User-Agent: KMail/1.13.7 (Linux/3.2.0-1-686-pae; KDE/4.7.4; i686; ; )
References: <CA+8xBpdD31koaVBh1RuDZKH1sygr8z10K=bPz8DepqYOa8i6yg@mail.gmail.com>
<201206160916.24485.andyparkins@gmail.com>
<CA+s+GJA2-+HuRFfX3b=-4wv7u9iFCnfOMyDKwekxmipszt27Cw@mail.gmail.com>
In-Reply-To: <CA+s+GJA2-+HuRFfX3b=-4wv7u9iFCnfOMyDKwekxmipszt27Cw@mail.gmail.com>
MIME-Version: 1.0
Message-Id: <201206161054.11537.andyparkins@gmail.com>
Content-Type: Text/Plain;
charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.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
(andyparkins[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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: 1Sfpi2-0000ao-9h
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 09:54:23 -0000
On Saturday 16 Jun 2012 09:42:21 Wladimir wrote:
> 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.
My problem is that that I suspect the spectrum of clients will be far more
than simply "thin" or "thick". What about thick-pruned, thick-full? What
about thin-blocks-on-demand and thin-headers-on-demand? These are just what
I can think of now; it seems unwise to limit the functionality of clients
not yet designed with a binary designation. So... we make a field that can
hold more than just a bit; with each possible value representing a specific
(possibly overlapping) set of features? Why not just enumerate the features
then?
I did write responses to each of your following points; but they just
sounded like me being contrary. The short version is that I think too much
emphasis is being placed on defining a specific set of feature->version
mapping. That's going to make it hard for future clients that want to
implement some of the features but not all, and yet still want to be good
bitcoin citizens and be able to tell their peers what they don't support.
For example, there is no easy way for a node to tell another that it doesn't
have the whole block chain available, so requesting it from it will fail.
> I'm just afraid that the currently simple P2P protocol will turn into a
> zoo of complicated (and potentially buggy/insecure) interactions.
Fair enough.
> 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.
That problem doesn't go away just because you don't have a capabilities
system. Either version 11 can speak version 10 or it can't. I don't see
how having a system for finding out that fact changes anything other than
removing a load of protocol noise.
"I support getdata10" makes it far easier to discover that the peer supports
getdata10 than sending getdata11 and watching it fail does.
Andy
--
Dr Andy Parkins
andyparkins@gmail.com
|
