Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of bitpay.com
	designates 209.85.213.177 as permitted sender)
	client-ip=209.85.213.177; envelope-from=jgarzik@bitpay.com;
	helo=mail-ig0-f177.google.com; 
MIME-Version: 1.0
In-Reply-To: <CANEZrP1mhSodC-ZvkuVKAgHO44bM7QX=RivRDhnDeHOKr8PXqQ@mail.gmail.com>
References: <CAJHLa0Ok6s5xQcMSeLa69adLBXEaicuXqcg45eZrwYtVFbx-dA@mail.gmail.com>
	<CANEZrP2wYcxJhxRRa86Nm9ENtK2SA5VNG-L7f5pHb_W=Ajcj5Q@mail.gmail.com>
	<CA+s+GJD+9qpwFcVfHOCCsFYjmk7A0V=65vG-7jJ6D7jj4Pi_7g@mail.gmail.com>
	<CANEZrP245242JYDBBo72XVmKgEBO96QPjcJi8Jy2Dm_r90n1Bw@mail.gmail.com>
	<CAJHLa0N3xx1QZ==iSLYNsdgkBGoqN34+4eVtukkjn+3SrDhC7A@mail.gmail.com>
	<CANEZrP1mhSodC-ZvkuVKAgHO44bM7QX=RivRDhnDeHOKr8PXqQ@mail.gmail.com>
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Fri, 8 Aug 2014 08:04:16 -0400
Message-ID: <CAJHLa0MOn5XxAFzqDPgvM=jrr8PRx=Lkatpw30xZqiOQDaK52Q@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>, Wladimir van der Laan <laanwj@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related
	services
Precedence: list

Yes, that is the one change I am still pondering:  adding categories
(classes), rather than one single bit.

Thus the modified proposal would become:
- eliminate NODE_EXT_SERVICES
- for a class of services, such as insight w/ added blockchain indexes
& queries, add NODE_EXT_INDEXED_CHAIN
- for another class of services, add NODE_EXT_xxxx
- Re-use the same P2P message and structure (CExtService,
"extservices" P2P message) for all NODE_EXT_xxx classes.

This preserves vendor/API neutrality, while saving effort on the part
of clients seeking these services.  The point about service discovery
necessitating some node walking is valid, which makes categories
somewhat attractive.

"Having the service run on some arbitrary other port isn't
particularly useful, IMO" --  A statement disproved by reality.
Multi-port is the method most commonly found in the field today.
Logically so, because it is the easiest to deploy:

* The most likely setup TODAY is multi-daemon: bitcoind + your own software
* The most likely configuration for multi-daemon is self-evidently
multi-port (versus two services appearing on the same port)

It is quite useful, and indeed, the most likely setup to be found in operation.


On Fri, Aug 8, 2014 at 7:38 AM, Mike Hearn <mike@plan99.net> wrote:
> I'd like to see a mechanism whereby a Bitcoin node can delegate processing
> of unknown messages to an external process, so a P2P node can be composed
> out of separated programs, but such a service would be indistinguishable at
> the network layer from one provided by Bitcoin Core itself, so a service bit
> would be appropriate for those.
>
> For instance, Insight could then offer a command set that extends the p2p
> protocol for doing block explorer type queries. There's no need for the
> protocol to be Insight specific.  You'd just have NODE_INDEXED_CHAIN
> instead.
>
> Having the service run on some arbitrary other port isn't particularly
> useful, IMO - the biggest win from having some separated protocol would be
> the ability to use TLS, but if you're connecting to an IP address rather
> than a domain name (like if you discovered via service bits/getextsrv) this
> doesn't add much. It boils down to minor syntax differences in how numbers
> are laid out in a grid. And the performance issue remains.
>
> Additionally, nothing in this spec requires that a local bitcoind be
> running. What stops someone from advertising just NODE_EXTENDED_SERVICES and
> nothing else? I don't think a generic service advertisement mechanism is a
> bad thing to have, by the way, just pointing out that nothing makes this
> more focused than service bits already are.


-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/