1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
|
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 <jgarzik@bitpay.com>) 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 <bitcoin-development@lists.sourceforge.net>;
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: <CANEZrP1mhSodC-ZvkuVKAgHO44bM7QX=RivRDhnDeHOKr8PXqQ@mail.gmail.com>
References: <CAJHLa0Ok6s5xQcMSeLa69adLBXEaicuXqcg45eZrwYtVFbx-dA@mail.gmail.com>
<CANEZrP2wYcxJhxRRa86Nm9ENtK2SA5VNG-L7f5pHb_W=Ajcj5Q@mail.gmail.com>
<CA+s+GJD+9qpwFcVfHOCCsFYjmk7A0V=65vG-7jJ6D7jj4Pi_7g@mail.gmail.com>
<CANEZrP245242JYDBBo72XVmKgEBO96QPjcJi8Jy2Dm_r90n1Bw@mail.gmail.com>
<CAJHLa0N3xx1QZ==iSLYNsdgkBGoqN34+4eVtukkjn+3SrDhC7A@mail.gmail.com>
<CANEZrP1mhSodC-ZvkuVKAgHO44bM7QX=RivRDhnDeHOKr8PXqQ@mail.gmail.com>
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Fri, 8 Aug 2014 08:04:16 -0400
Message-ID: <CAJHLa0MOn5XxAFzqDPgvM=jrr8PRx=Lkatpw30xZqiOQDaK52Q@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>, Wladimir van der Laan <laanwj@gmail.com>
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 <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <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/
|
