NODE_EXT_SERVICE: Advertise other services also available at this node. #4657

1. 
   jgarzik commented at 3:32 am on August 8, 2014: contributor

   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. </vendor hat>

   Obviously, we want to build this in a generic, vendor-neutral way.

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

2. Advertise other services also available at this node. 416f60d0a8
3. in src/extservices.cpp: in 416f60d0a8 outdated

   0@@ -0,0 +1,195 @@
   1+
   

   ---

   ---

   

   Diapolo commented at 5:44 am on August 8, 2014:

   Can you at least try to respect the coding style rules we have (include ordering etc.)?

   ---

   

   jgarzik commented at 11:40 am on August 8, 2014:

   If this continues to produce hectoring, then the most appropriate action is to remove that rule from doc/coding.md. At some point you need to ask yourself whether this is satisfying your personal OCD versus making the bitcoin project and its developers more (or less!) productive.

   ---

   

   rebroad commented at 2:13 am on September 6, 2014:

   @Diapolo is quite right to point this out if it goes against coding standards and @jgarzik is quite right to point out that the coding standards may need revising.

   May I take this moment to suggest reading the “four agreements”? (http://crossfitcetro.com/wp-content/uploads/2012/08/the_four_agreements.jpg) - I’m seeing all too often people taking things a bit too personally on here, however, it could almost go without saying that I for one am grateful to @jgarzik for so many of the code changes he’s contributed, and I hope other user’s sterling efforts (OCD fuelled or not) to enforce style rules don’t deter future contributions.

   ---

   

   laanwj commented at 2:26 am on September 6, 2014:

   It makes sense to have a well-defined coarse include order. I.e. first your own include, then dependencies within the project, then dependencies outside the project. This makes sure that the compiler checks that your own include file (in this case extservices.h) includes everything it needs on its own.

   As for alphabetical sorting, it could be argued that that is a step too far, although if you want to define some fixed ordering within the groups alphabetical makes most sense. For example it makes it easier to see duplicates.

4. in src/protocol.h: in 416f60d0a8 outdated

   63@@ -64,6 +64,7 @@ class CMessageHeader
   64 enum
   65 {
   66     NODE_NETWORK = (1 << 0),
   67+    NODE_EXT_SERVICES = (1 << 1),
   

   ---

   ---

   

   laanwj commented at 7:25 am on August 8, 2014:

   This collides with NODE_GETUTXO in #4351 / BIP 64
5. laanwj added the label Feature on Aug 8, 2014
6. NODE_EXT_SERVICES: Fix bug. Avoid bit #1, used by conflicting proposal. ee3274f94d
7. 
   BitcoinPullTester commented at 11:49 am on August 8, 2014: none

   Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/p4657_ee3274f94d94833efe364346d2c74d8be6a18a83/ for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.
8. 
   dajohi commented at 3:54 pm on August 8, 2014: contributor

   I’d recommend using uint16 for the port instead of int32. You can use 0 for “invalid”. A port has always been uint16, and making it int32 just seems odd.
9. jgarzik added the label P2P on Aug 8, 2014
10. 
    laanwj commented at 7:44 am on May 18, 2015: member

    How is the process side of this moving forward? I know it has been discussed on the mailing list on some point, but I think it still needs e.g. a BIP number.
11. 
    laanwj commented at 10:05 am on May 27, 2015: member

    Closing for now, as no active development is happening on this.
12. laanwj closed this on May 27, 2015

    ---

13. MarcoFalke locked this on Sep 8, 2021

Contributors
jgarzik Diapolo rebroad laanwj BitcoinPullTester dajohi

Labels
Feature P2P