Author: Jeff Garzik 2014-08-08 12:04:16
Published on: 2014-08-08T12:04:16+00:00
The discussion revolves around the proposal to add categories (classes) instead of a single bit in Bitcoin node services. The modified proposal suggests eliminating NODE_EXT_SERVICES and adding NODE_EXT_INDEXED_CHAIN for a class of services such as insight w/ added blockchain indexes & queries. For another class of services, NODE_EXT_xxxx should be added, and the same P2P message and structure (CExtService, "extservices" P2P message) should be reused for all NODE_EXT_xxx classes. This change will preserve vendor/API neutrality and save effort on the clients' part seeking these services. Service discovery requiring node-walking makes categories somewhat attractive.The statement that having the service run on some arbitrary other port isn't particularly useful is challenged by reality. Multi-port is the most commonly found method in the field today since it is the easiest to deploy. Most setups today are multi-daemon: bitcoind + your software, and 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.Mike Hearn suggests a mechanism where a Bitcoin node can delegate processing of unknown messages to an external process, so a P2P node can be composed out of separated programs. Such a service would be indistinguishable at the network layer from one provided by Bitcoin Core itself. Jeff Garzik, a Bitcoin core developer and open-source evangelist, supports the idea of generic service advertisement mechanisms. However, he points out that nothing makes the proposal more focused than service bits already are.
Updated on: 2023-06-09T02:02:52.165223+00:00