Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.223.179 as permitted sender)
	client-ip=209.85.223.179; envelope-from=laanwj@gmail.com;
	helo=mail-ie0-f179.google.com; 
MIME-Version: 1.0
In-Reply-To: <CAJHLa0Mk5E4ubQ2MZcdrG3fAm5KAATKsSgxnN8VKN1W=uBU0Og@mail.gmail.com>
References: <20140617072351.GA7205@savin>
	<CA+s+GJAgQAZzwgONbD==fYTsV9jWKCZ6+gTiwohUT_H5kT_MoA@mail.gmail.com>
	<CAJHLa0Mk5E4ubQ2MZcdrG3fAm5KAATKsSgxnN8VKN1W=uBU0Og@mail.gmail.com>
Date: Wed, 18 Jun 2014 08:20:26 +0200
Message-ID: <CA+s+GJB-PziMMYDJMFYX6vAu-FCfugeJrNe+n3aLokFcFvzvEA@mail.gmail.com>
From: Wladimir <laanwj@gmail.com>
To: Jeff Garzik <jgarzik@bitpay.com>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <Bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal: allocate 8 service bits for
 experimental use
Precedence: list

On Tue, Jun 17, 2014 at 11:29 PM, Jeff Garzik <jgarzik@bitpay.com> wrote:
> I wrote a patch for string-based name extensions, circa 2011-2012.  I
> agree that is preferable to unreadable bits, for reasons you cite.
>
> However, it was noted that extensions (or UUIDs etc.) would not be
> propagated around the network in "addr" messages, as service bits are.

Thanks for letting me know, I didn't remember your patch.

Ugh, yes, propagating all extensions in `addr` messages is not how I
imagined this to work.

But then there would need to be an alternative way to discover nodes
that offer a certain extension. Alas, this moves it from a
straightforward and common sense change to a significant change to the
protocol.

Wladimir