summaryrefslogtreecommitdiff
path: root/60/ad38a6af69e71fcc086e9f96868241fe586a3a
blob: 42cffef480937efadfc6fc5a2b2c814c9642a315 (plain)
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
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <andyparkins@gmail.com>) id 1SfoBP-0002i9-RS
	for bitcoin-development@lists.sourceforge.net;
	Sat, 16 Jun 2012 08:16:35 +0000
Received-SPF: pass (sog-mx-1.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-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1SfoBP-00014z-6h
	for bitcoin-development@lists.sourceforge.net;
	Sat, 16 Jun 2012 08:16:35 +0000
Received: by werg55 with SMTP id g55so2920608wer.34
	for <bitcoin-development@lists.sourceforge.net>;
	Sat, 16 Jun 2012 01:16:29 -0700 (PDT)
Received: by 10.180.82.198 with SMTP id k6mr9988494wiy.20.1339834588995;
	Sat, 16 Jun 2012 01:16:28 -0700 (PDT)
Received: from grissom.localnet ([91.84.15.31])
	by mx.google.com with ESMTPS id gc6sm8813986wib.0.2012.06.16.01.16.28
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 16 Jun 2012 01:16:28 -0700 (PDT)
From: Andy Parkins <andyparkins@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Date: Sat, 16 Jun 2012 09:16:24 +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>
	<1339810493.15660.YahooMailNeo@web121004.mail.ne1.yahoo.com>
	<CA+s+GJCKSrJv4L=4Nj4Hs+j2vfM-oWe5ayD_4NOUJMoXCkm3iA@mail.gmail.com>
In-Reply-To: <CA+s+GJCKSrJv4L=4Nj4Hs+j2vfM-oWe5ayD_4NOUJMoXCkm3iA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201206160916.24485.andyparkins@gmail.com>
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: 1SfoBP-00014z-6h
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:16:35 -0000

On Saturday 16 Jun 2012 07:45:00 Wladimir wrote:
> 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.

It's less of a problem in a (nearly) stateless protocol like Bitcoin.

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.



Andy

-- 
Dr Andy Parkins
andyparkins@gmail.com