Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XFiuY-0003bm-ID for bitcoin-development@lists.sourceforge.net; Fri, 08 Aug 2014 12:04:42 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of bitpay.com designates 209.85.213.177 as permitted sender) client-ip=209.85.213.177; envelope-from=jgarzik@bitpay.com; helo=mail-ig0-f177.google.com; Received: from mail-ig0-f177.google.com ([209.85.213.177]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XFiuX-0007BS-Le for bitcoin-development@lists.sourceforge.net; Fri, 08 Aug 2014 12:04:42 +0000 Received: by mail-ig0-f177.google.com with SMTP id hn18so887503igb.16 for ; Fri, 08 Aug 2014 05:04:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=brUs9Rprh04s25BvLD65Sr8PJoMdt51vaChXnIk6MJo=; b=HsmIWYTuzrm8YvLv7zPGFM+gyWA8Fg91tLU86bG1avaSmXw71lFdlujt0cCVEw7dRT iqR+Ckmmh/Lq1E0LP5DVnmCe8GizSMjbvBqhCwZHafcZKR7SFKsJjyb7o07uqI3WijzD usQkpN7TVRpVLZIFSTlCez5xDLTlKSNztlBlR9WuqLXcCV6LIKEEfc4lA3AOE5AsuZc+ G1qOtp/Ivlk76OAXuekwNyprrn2B+DUAa+jBoWubJXYuIQ3DrsB2DwmGAeuQeDTxtWzx V5I91tzyplR3ciJnZ8fzedIY5qIAY0MpVsKrm7OBS4kEOEd99knbVw4Omw3KsH6jfLEv DP5g== X-Gm-Message-State: ALoCoQke9PaeDG7HgLq5Tzag8v5VgS7FBklClsjsT6r9Ci975snINY6UkcL32juzHYBFA6web+3k X-Received: by 10.50.107.7 with SMTP id gy7mr4384122igb.15.1407499476364; Fri, 08 Aug 2014 05:04:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.10.78 with HTTP; Fri, 8 Aug 2014 05:04:16 -0700 (PDT) In-Reply-To: References: From: Jeff Garzik Date: Fri, 8 Aug 2014 08:04:16 -0400 Message-ID: To: Mike Hearn , Wladimir van der Laan Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1XFiuX-0007BS-Le Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 12:04:42 -0000 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 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/