MIME-Version: 1.0
Date: Wed, 16 May 2012 14:18:27 -0400
Message-ID: <CA+8xBpd-0nXdda4fwyFonEY6rOSSyt=5goD-rbMTpvkcuHNTog@mail.gmail.com>
From: Jeff Garzik <jgarzik@exmulti.com>
To: Amir Taaki <zgenjix@yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Subject: [Bitcoin-development] P2P feature discovery (was Re: BIP 33 -
 Stratized Nodes)
Precedence: list

On Wed, May 16, 2012 at 12:34 PM, Amir Taaki <zgenjix@yahoo.com> wrote:
> Please check out my proposal,
>
> https://en.bitcoin.it/wiki/BIP_0033
>
> I want to use the existing Bitcoin protocol to provide this functionality=
 in order to maintain compatibility. This proposal does not affect current =
Bitcoin clients, but allows the parallel system to operate alongside and so=
metimes intersect with the main Bitcoin network in a positive way.


I do not object to the concept, but the discovery process should be
improved.  Even venerable SMTP has a better, more flexible
capabilities discovery process.

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.

Standard behavior of clients would be to send "get-features" after
seeing remote version info, as part of the initial connection
handshake.

In any case, the basic point is to move FAR away from fighting over a
limited, inflexible resource (service bits in "version" msg) to
something string-based and easily extensible.

I can create this as BIP 34, if people wish.

--=20
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti.com