From: Jeff Garzik <jgarzik@bitpay•com>
To: Mike Hearn <mike@plan99•net>, Wladimir van der Laan <laanwj@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
Date: Fri, 8 Aug 2014 08:04:16 -0400 [thread overview]
Message-ID: <CAJHLa0MOn5XxAFzqDPgvM=jrr8PRx=Lkatpw30xZqiOQDaK52Q@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP1mhSodC-ZvkuVKAgHO44bM7QX=RivRDhnDeHOKr8PXqQ@mail.gmail.com>
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/
next prev parent reply other threads:[~2014-08-08 12:04 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-08 3:38 Jeff Garzik
2014-08-08 9:45 ` Mike Hearn
2014-08-08 9:56 ` Wladimir
2014-08-08 10:01 ` Mike Hearn
2014-08-08 10:15 ` Wladimir
2014-08-08 10:26 ` Wladimir
2014-08-08 10:41 ` Christian Decker
2014-08-08 11:22 ` Jeff Garzik
2014-08-08 11:33 ` Jeff Garzik
2014-08-08 11:38 ` Mike Hearn
2014-08-08 11:59 ` Wladimir
2014-08-08 12:06 ` Jeff Garzik
2014-08-08 12:11 ` Jeff Garzik
2014-08-08 12:15 ` Wladimir
2014-08-08 12:11 ` Mike Hearn
2014-08-08 12:15 ` Jeff Garzik
2014-08-08 12:16 ` Wladimir
2014-08-08 12:34 ` Wladimir
2014-08-08 13:55 ` Mike Hearn
2014-08-08 12:04 ` Jeff Garzik [this message]
2014-08-08 12:13 ` Mike Hearn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJHLa0MOn5XxAFzqDPgvM=jrr8PRx=Lkatpw30xZqiOQDaK52Q@mail.gmail.com' \
--to=jgarzik@bitpay$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=laanwj@gmail$(echo .)com \
--cc=mike@plan99$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox