Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.213.175 as permitted sender)
	client-ip=209.85.213.175; envelope-from=gmaxwell@gmail.com;
	helo=mail-yx0-f175.google.com; 
MIME-Version: 1.0
In-Reply-To: <CA+8xBpfZzxBgqO6xT6+a_ACgYR=3cV9rmY_kmSovtT3dfjdhDg@mail.gmail.com>
References: <5028AFBE.8070104@justmoon.de>
	<CA+8xBpfZzxBgqO6xT6+a_ACgYR=3cV9rmY_kmSovtT3dfjdhDg@mail.gmail.com>
Date: Mon, 13 Aug 2012 11:07:55 -0400
Message-ID: <CAAS2fgSgE0fOetuJZDPVeEMxbDo91r0w3Hvvn4vDdChCH1zxdA@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Jeff Garzik <jgarzik@exmulti.com>
Content-Type: text/plain; charset=UTF-8
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] BIP: Custom Services
Precedence: list

On Mon, Aug 13, 2012 at 10:24 AM, Jeff Garzik <jgarzik@exmulti.com> wrote:
> My only response is a weak one:  inevitability.  It seems likely that
> -somebody- will implement their own P2P commands for their own client
> subset, even if only a simple "use 'getstatus' with strSubVer matching
> /FooClient/"
>
> Therefore, if it is inevitable, we might as well make some basic rules
> about how to extended your P2P command set.

I'm not opposed to that logic.  But for cases where an introduction mechanism
will be needed... it would be awfully good to have one, and I do think that
there is harm in making people think that simple services negotiation will
actually work for their needs for cases where a separate p2p network is
needed.