From: "Luke-Jr" <luke@dashjr.org>
To: bitcoin-development@lists.sourceforge.net
Date: Wed, 16 May 2012 18:29:41 +0000
User-Agent: KMail/1.13.7 (Linux/3.2.12-gentoo; KDE/4.8.1; x86_64; ; )
References: <CA+8xBpd-0nXdda4fwyFonEY6rOSSyt=5goD-rbMTpvkcuHNTog@mail.gmail.com>
In-Reply-To: <CA+8xBpd-0nXdda4fwyFonEY6rOSSyt=5goD-rbMTpvkcuHNTog@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201205161829.44967.luke@dashjr.org>
Subject: Re: [Bitcoin-development] P2P feature discovery (was Re: BIP 33 -
	Stratized Nodes)
Precedence: list

On Wednesday, May 16, 2012 6:18:27 PM Jeff Garzik wrote:
> Instead of further overloading service bits in the version message, or
> altering the version message, let us instead make feature discovery an
> easy, flexible, extensible process.
> 
> We can add new commands without impacting older nodes, so let's create
> a new command "get-features" (or pick your name) that returns a list
> of key/value pairs.  The key is a string, the value type is determined
> by the key.

That assumes you already have a connection to the peer in question.
As I understand it, the service bits are propagated as part of the address, 
so you can see at a glance which nodes you want to connect to for some 
special service. Passing a huge list along might be unwieldy (though it 
makes sense for protocol changes that don't add new services).