Mike Hearn [ARCHIVE] on Nostr: 📅 Original date posted:2014-08-08 📝 Original message:I'd like to see a ...
📅 Original date posted:2014-08-08
📝 Original message: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140808/6e47949e/attachment.html>;
📝 Original message: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140808/6e47949e/attachment.html>;