[Bitcoin-development] NODE_EXT_SERVICES and advertising related services

[Bitcoin-development] NODE_EXT_SERVICES and advertising related services

[Jeff Garzik]

Link: https://github.com/bitcoin/bitcoin/pull/4657

It is not necessary to build all functionality into bitcoind, to form
a decentralized network. BitPay's insight open source block explorer
API project requires, and runs on top of, bitcoind. Therefore, at the
same IP address as bitcoind, other services are made available to the
public (scriptPubkey queries, other added-value queries). This results
in a decentralized network of "anyone running a full node and an
insight server", as a subset of the whole P2P net.  One then does not
need to trust BitPay's insight server, but may query any number of
insight servers from multiple operators, and survey the results.

Obviously, we want to build this in a generic, vendor-neutral way.  As
such, NODE_EXT_SERVICES is advertised via the "addr" P2P message.
Nodes that recognize the NODE_EXT_SERVICES bit may connect to that
node, query a services list via "getextsrv" P2P message, and then take
further action based on the results.  The results are quite
straightforward:

service name, service port (or -1 if undefined), list of string
key/value attribs

Services may only advertise added services if and only if the external
services are at the same IP address that is being advertised.

This is not a fully baked proposal by any means, but more of a trial
balloon to get discussion moving.

There is no need to implement all services inside bitcoind...

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

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 245 bytes --]

Given that we're not running out of service bits and service bits mean you
don't have to try connecting to every node to find out what services it
supports, why not keep using the existing extension mechanism until we
start running out of bits?

[-- Attachment #2: Type: text/html, Size: 275 bytes --]

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

[Wladimir]

On Fri, Aug 8, 2014 at 11:45 AM, Mike Hearn <mike@plan99.net> wrote:
> Given that we're not running out of service bits and service bits mean you
> don't have to try connecting to every node to find out what services it
> supports, why not keep using the existing extension mechanism until we start
> running out of bits?

He wants to use it to advertise services that are not part of the P2P
protocol itself, but run on a different port. Reserving services bits
for those is not acceptable.

All the NODE_EXT_SERVICES bit does is advertise the P2P "getextsrv"
command to get information, such as the port to connect on, for the
auxilary service.

Wladimir

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]

>
> He wants to use it to advertise services that are not part of the P2P
> protocol itself, but run on a different port. Reserving services bits
> for those is not acceptable.
>

Why not? Does the port matter much?


> All the NODE_EXT_SERVICES bit does is advertise the P2P "getextsrv"
> command to get information, such as the port to connect on, for the
> auxilary service.


Yes, I understand what it does, but from a clients perspective what it
means is if someone implements a useful service and exposes it this way you
have to seek out, connect to and interrogate every possible server even if
(say) only a handful actually provide it. The most there's >1 "ext service"
the protocol becomes extremely slow, vs service bits where you can download
addr packets and see which IPs are advertising which services.

I don't see much reason to take a potentially large performance hit when
there's a service advertisement mechanism that already works. What's wrong
with the existing mechanism exactly?

[-- Attachment #2: Type: text/html, Size: 1544 bytes --]

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

[Wladimir]

On Fri, Aug 8, 2014 at 12:01 PM, Mike Hearn <mike@plan99.net> wrote:
>> He wants to use it to advertise services that are not part of the P2P
>> protocol itself, but run on a different port. Reserving services bits
>> for those is not acceptable.
>
>
> Why not? Does the port matter much?

Yes. The services bits are for advertising services on the P2P
network. That's not open for discussion.

Wladimir

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

[Wladimir]

On Fri, Aug 8, 2014 at 12:15 PM, Wladimir <laanwj@gmail.com> wrote:
> On Fri, Aug 8, 2014 at 12:01 PM, Mike Hearn <mike@plan99.net> wrote:
>>> He wants to use it to advertise services that are not part of the P2P
>>> protocol itself, but run on a different port. Reserving services bits
>>> for those is not acceptable.
>>
>>
>> Why not? Does the port matter much?
>
> Yes. The services bits are for advertising services on the P2P
> network. That's not open for discussion.

It also wouldn't work. A bit is not enough to find an external service
except in the naive case where the advertised service would have a
fixed port. Not even bitcoind has a fixed port. So there needs to be a
mechanism to find how to connect to the 'external service'. This is
provided by the proposed extension.

It would in principle be possible to advertise an extra service bit
*in addition to* this one, to make it easier to find through the addr
mechanism. But it  would be confusing and IMO an abuse of P2P service
bits.

Wladimir

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

[Christian Decker]

[-- Attachment #1: Type: text/plain, Size: 2142 bytes --]

I wonder whether we actually want to support this kind of advertisement in
the P2P protocol. We have a working mechanism for protocol extensions in
the P2P network (service flags) so this is obviously only for services that
are not P2P extensions, so why have them in there at all?

I'd argue that a parallel network, external to Bitcoin, could take over the
task of advertising external services.

Regards,
Chris

--
Christian Decker


On Fri, Aug 8, 2014 at 11:26 AM, Wladimir <laanwj@gmail.com> wrote:

> On Fri, Aug 8, 2014 at 12:15 PM, Wladimir <laanwj@gmail.com> wrote:
> > On Fri, Aug 8, 2014 at 12:01 PM, Mike Hearn <mike@plan99.net> wrote:
> >>> He wants to use it to advertise services that are not part of the P2P
> >>> protocol itself, but run on a different port. Reserving services bits
> >>> for those is not acceptable.
> >>
> >>
> >> Why not? Does the port matter much?
> >
> > Yes. The services bits are for advertising services on the P2P
> > network. That's not open for discussion.
>
> It also wouldn't work. A bit is not enough to find an external service
> except in the naive case where the advertised service would have a
> fixed port. Not even bitcoind has a fixed port. So there needs to be a
> mechanism to find how to connect to the 'external service'. This is
> provided by the proposed extension.
>
> It would in principle be possible to advertise an extra service bit
> *in addition to* this one, to make it easier to find through the addr
> mechanism. But it  would be confusing and IMO an abuse of P2P service
> bits.
>
> Wladimir
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 3094 bytes --]

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

[Jeff Garzik]

This is not a generic "I run a website!" advertisement feature.
NODE_EXT_SERVICES is tightly focused on services that exist
if-any-only-if a P2P bitcoin node (bitcoind) is reachable via the same
advertised address.

You may usefully create overlay networks of specialized services.



On Fri, Aug 8, 2014 at 6:41 AM, Christian Decker
<decker.christian@gmail.com> wrote:
> I wonder whether we actually want to support this kind of advertisement in
> the P2P protocol. We have a working mechanism for protocol extensions in the
> P2P network (service flags) so this is obviously only for services that are
> not P2P extensions, so why have them in there at all?
>
> I'd argue that a parallel network, external to Bitcoin, could take over the
> task of advertising external services.
>
> Regards,
> Chris
>
> --
> Christian Decker
>
>
> On Fri, Aug 8, 2014 at 11:26 AM, Wladimir <laanwj@gmail.com> wrote:
>>
>> On Fri, Aug 8, 2014 at 12:15 PM, Wladimir <laanwj@gmail.com> wrote:
>> > On Fri, Aug 8, 2014 at 12:01 PM, Mike Hearn <mike@plan99.net> wrote:
>> >>> He wants to use it to advertise services that are not part of the P2P
>> >>> protocol itself, but run on a different port. Reserving services bits
>> >>> for those is not acceptable.
>> >>
>> >>
>> >> Why not? Does the port matter much?
>> >
>> > Yes. The services bits are for advertising services on the P2P
>> > network. That's not open for discussion.
>>
>> It also wouldn't work. A bit is not enough to find an external service
>> except in the naive case where the advertised service would have a
>> fixed port. Not even bitcoind has a fixed port. So there needs to be a
>> mechanism to find how to connect to the 'external service'. This is
>> provided by the proposed extension.
>>
>> It would in principle be possible to advertise an extra service bit
>> *in addition to* this one, to make it easier to find through the addr
>> mechanism. But it  would be confusing and IMO an abuse of P2P service
>> bits.
>>
>> Wladimir
>>
>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



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

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

[Jeff Garzik]

n Fri, Aug 8, 2014 at 6:01 AM, Mike Hearn <mike@plan99.net> wrote:
> What's wrong
> with the existing mechanism exactly?

It would be wrong to add NODE_INSIGHT, NODE_ELECTRUM_SERVER, etc. bits
even though you do have useful bitcoin-related APIs that exist on the
same system as bitcoind.

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

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1328 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1459 bytes --]

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

[Wladimir]

On Fri, Aug 8, 2014 at 1:38 PM, 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.

This diverges from the topic but seems like a good idea to me in
general, not so much as replacement for jgarzik's proposal.

Something like `getutxos` or this proposal could be implemented as an
external application or script, instead of having to integrate
everything into bitcoind.

Bitcoind would need a local interprocess message bus for that, and
would need to act as router for messages from/to the P2P network.
ZeroMQ seems like a good choice for that. That's not completely crazy
as there are already plans to add zeromq as an optional dependency for
notifications [1].

[1] https://github.com/bitcoin/bitcoin/pull/4594

Wladimir

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

[Jeff Garzik]

On Fri, Aug 8, 2014 at 7:59 AM, Wladimir <laanwj@gmail.com> wrote:
> On Fri, Aug 8, 2014 at 1:38 PM, 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.
>
> This diverges from the topic but seems like a good idea to me in
> general, not so much as replacement for jgarzik's proposal.
>
> Something like `getutxos` or this proposal could be implemented as an
> external application or script, instead of having to integrate
> everything into bitcoind.

Seconded.  Command plug-ins and such seem like an idea worth exploring.

We don't need to shove everything into bitcoind.

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

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

[Jeff Garzik]

On Fri, Aug 8, 2014 at 7:59 AM, Wladimir <laanwj@gmail.com> wrote:
> Bitcoind would need a local interprocess message bus for that, and
> would need to act as router for messages from/to the P2P network.
> ZeroMQ seems like a good choice for that. That's not completely crazy
> as there are already plans to add zeromq as an optional dependency for
> notifications [1].

Generally agreed, though for ZMQ it is a bit different than a P2P service.

IMO, ZMQ really wants to be a plug-in that registers some internal
signals.  It wants to capture the precise points where a block was
accepted internally.  PR #4599 tries to lead by example:
https://github.com/bitcoin/bitcoin/pull/4599

A P2P service would be a slightly different sort of plug-in.

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

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

[Wladimir]

> Generally agreed, though for ZMQ it is a bit different than a P2P service.
>
> IMO, ZMQ really wants to be a plug-in that registers some internal
> signals.  It wants to capture the precise points where a block was
> accepted internally.  PR #4599 tries to lead by example:
> https://github.com/bitcoin/bitcoin/pull/4599
>
> A P2P service would be a slightly different sort of plug-in.

ZeroMQ is just a lightweight message routing system. It could just as
well make P2P messages available to other applications (if they
subscribe to them). The other way around, routing messages from ZeroMQ
to certain P2P clients, is easy.

Wladimir

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1382 bytes --]

>
> Something like `getutxos` or this proposal could be implemented as an
> external application or script, instead of having to integrate
> everything into bitcoind.
>

Right, although getutxos needs access to the UTXO set which bitcoind
already has. An external plugin would have to recalculate it from scratch
which seems redundant.

However there are many other useful services that could be added in such a
way, like -txindex or the nLockTime storage facility we talked about the
other day.


> Bitcoind would need a local interprocess message bus for that


Maybe, that feels like it could be overkill though. Probably just something
like

./bitcoind -servicecookie=<long random string> -allowextservices=127.0.0.1/8

and then any program can connect to bitcoind as normal, send "registersrv"
with the cookie and a list of command ids it's interested in, maybe a
service bit to set, and start receiving those messages wrapped in a new
structure that gives some kind of client ID (like IP address). So any
library that can do the basic P2P protocol could then be extended with not
much code to get a multiplexed stream of messages from different clients.

An additional standalone program can then bridge this mechanism to running
a shell command for particular messages, though given the history of shell
based exploits I'd feel safer with something that doesn't do that ....

[-- Attachment #2: Type: text/html, Size: 1924 bytes --]

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

[Jeff Garzik]

getutxos is a special case, since we already maintain that index as
part of normal operation.

While I dislike some aspects of getutxos (covered elsewhere), if
merged, it would be more appropriate as a special case to keep
getutxos fully internal to bitcoind for implementation reasons.

On Fri, Aug 8, 2014 at 8:11 AM, Mike Hearn <mike@plan99.net> wrote:
>> Something like `getutxos` or this proposal could be implemented as an
>> external application or script, instead of having to integrate
>> everything into bitcoind.
>
>
> Right, although getutxos needs access to the UTXO set which bitcoind already
> has. An external plugin would have to recalculate it from scratch which
> seems redundant.
>
> However there are many other useful services that could be added in such a
> way, like -txindex or the nLockTime storage facility we talked about the
> other day.
>
>>
>> Bitcoind would need a local interprocess message bus for that
>
>
> Maybe, that feels like it could be overkill though. Probably just something
> like
>
> ./bitcoind -servicecookie=<long random string> -allowextservices=127.0.0.1/8
>
> and then any program can connect to bitcoind as normal, send "registersrv"
> with the cookie and a list of command ids it's interested in, maybe a
> service bit to set, and start receiving those messages wrapped in a new
> structure that gives some kind of client ID (like IP address). So any
> library that can do the basic P2P protocol could then be extended with not
> much code to get a multiplexed stream of messages from different clients.
>
> An additional standalone program can then bridge this mechanism to running a
> shell command for particular messages, though given the history of shell
> based exploits I'd feel safer with something that doesn't do that ....



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

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

[Wladimir]

On Fri, Aug 8, 2014 at 2:11 PM, Mike Hearn <mike@plan99.net> wrote:
>> Something like `getutxos` or this proposal could be implemented as an
>> external application or script, instead of having to integrate
>> everything into bitcoind.
>
>
> Right, although getutxos needs access to the UTXO set which bitcoind already
> has. An external plugin would have to recalculate it from scratch which
> seems redundant.

Well to play the devil's advocate, you could set it up to query the
information back over RPC :-)

But yeah, I didn't mean getutxos specifically, it has a trivial
implementation anyway.

Wladimir

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

[Wladimir]

On Fri, Aug 8, 2014 at 2:11 PM, Mike Hearn <mike@plan99.net> wrote:
> Maybe, that feels like it could be overkill though. Probably just something
> like
>
> ./bitcoind -servicecookie=<long random string> -allowextservices=127.0.0.1/8

I don't like conflating the external and internal interface. The
interface to the outside and the interface to the inside should be
well-separated.

I'd be OK with such an idea if bitcoind listens on a separate port for
connections from plugins, a port that cannot be used for normal P2P
traffic. This could also be a UNIX socket instead of a TCP port.

Wladimir

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 410 bytes --]

>
> I'd be OK with such an idea if bitcoind listens on a separate port for
> connections from plugins, a port that cannot be used for normal P2P
> traffic. This could also be a UNIX socket instead of a TCP port.


Yes, can be done this way too. I was thinking about setups where you have
services distributed across multiple machines. However a separate port does
indeed allow iptables or the like to be used.

[-- Attachment #2: Type: text/html, Size: 644 bytes --]

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

[Jeff Garzik]

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/

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 794 bytes --]

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

Sure, that makes more sense I think.

As a motivating use case, Bitcoin Wallet for Android currently has a
hard-coded block explorer (biteasy.com) which it uses to find UTXOs for a
given key. This is used for its "Sweep paper wallet" feature. It must work
this way because P2P nodes don't calculate such indexes.

If there was a way to do block index autodiscovery, that'd help us remove
this hard-coded block explorer and increase decentralisation. But because
it's a GUI app we don't want users to look at a spinner for more than a few
seconds, so a slow discovery process would make it unworkable. With
API-based categories of service bits we could implement such a scheme.

[-- Attachment #2: Type: text/html, Size: 1192 bytes --]