Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
> > 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. -- 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
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
On Fri, Aug 8, 2014 at 2:11 PM, Mike Hearn wrote: > Maybe, that feels like it could be overkill though. Probably just something > like > > ./bitcoind -servicecookie= -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 -- 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
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
On Fri, Aug 8, 2014 at 2:11 PM, Mike Hearn 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 -- 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
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
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 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= -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/ -- 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
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
> 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 -- 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
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
> > 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. -- 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
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
On Fri, Aug 8, 2014 at 7:59 AM, Wladimir 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/ -- 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
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
> > 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= -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 -- 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
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
On Fri, Aug 8, 2014 at 7:59 AM, Wladimir wrote: > On Fri, Aug 8, 2014 at 1:38 PM, Mike Hearn 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/ -- 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
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
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_ - 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 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/ -- 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
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
On Fri, Aug 8, 2014 at 1:38 PM, Mike Hearn 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 -- 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
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
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. -- 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
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
n Fri, Aug 8, 2014 at 6:01 AM, Mike Hearn 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/ -- 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
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
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 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 wrote: >> >> On Fri, Aug 8, 2014 at 12:15 PM, Wladimir wrote: >> > On Fri, Aug 8, 2014 at 12:01 PM, Mike Hearn 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/ -- 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
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
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 wrote: > On Fri, Aug 8, 2014 at 12:15 PM, Wladimir wrote: > > On Fri, Aug 8, 2014 at 12:01 PM, Mike Hearn 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
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
On Fri, Aug 8, 2014 at 12:15 PM, Wladimir wrote: > On Fri, Aug 8, 2014 at 12:01 PM, Mike Hearn 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
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
On Fri, Aug 8, 2014 at 12:01 PM, Mike Hearn 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 -- 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
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
> > 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? -- 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
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
On Fri, Aug 8, 2014 at 11:45 AM, Mike Hearn 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 -- 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
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
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? -- 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
[Bitcoin-development] NODE_EXT_SERVICES and advertising related services
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/ -- 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