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; 
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>
Subject: Re: [Bitcoin-development] Proposed new P2P command and response:
	getcmds, cmdlist
Precedence: list

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