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
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <decker.christian@gmail.com>) id 1XFhcv-0006Wk-M3
for bitcoin-development@lists.sourceforge.net;
Fri, 08 Aug 2014 10:42:25 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.52 as permitted sender)
client-ip=209.85.219.52;
envelope-from=decker.christian@gmail.com;
helo=mail-oa0-f52.google.com;
Received: from mail-oa0-f52.google.com ([209.85.219.52])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XFhcu-0003wn-GP
for bitcoin-development@lists.sourceforge.net;
Fri, 08 Aug 2014 10:42:25 +0000
Received: by mail-oa0-f52.google.com with SMTP id o6so3928471oag.11
for <bitcoin-development@lists.sourceforge.net>;
Fri, 08 Aug 2014 03:42:19 -0700 (PDT)
X-Received: by 10.60.52.178 with SMTP id u18mr30043958oeo.68.1407494539004;
Fri, 08 Aug 2014 03:42:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.76.3.161 with HTTP; Fri, 8 Aug 2014 03:41:38 -0700 (PDT)
In-Reply-To: <CA+s+GJDjSR3272LsSax-2V--x4_taoqrTMiDoXSEvuiS5-MBKw@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>
<CA+s+GJBUgi7XF4nyVEXqpZi4XYO86vTXMs40gzfu9tCdmp59tw@mail.gmail.com>
<CA+s+GJDjSR3272LsSax-2V--x4_taoqrTMiDoXSEvuiS5-MBKw@mail.gmail.com>
From: Christian Decker <decker.christian@gmail.com>
Date: Fri, 8 Aug 2014 11:41:38 +0100
Message-ID: <CALxbBHXPCpZ9npacPOgU2q6=xTpcOVi2fJ+C8v93U2Oyuorrgw@mail.gmail.com>
To: Wladimir <laanwj@gmail.com>
Content-Type: multipart/alternative; boundary=001a11330da805522005001bdc38
X-Spam-Score: -0.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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(decker.christian[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-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: 1XFhcu-0003wn-GP
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 10:42:25 -0000
--001a11330da805522005001bdc38
Content-Type: text/plain; charset=UTF-8
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
>
--001a11330da805522005001bdc38
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">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 fo=
r services that are not P2P extensions, so why have them in there at all?<d=
iv>
<br></div><div>I'd argue that a parallel network, external to Bitcoin, =
could take over the task of advertising external services.</div><div><br></=
div><div>Regards,</div><div>Chris</div></div><div class=3D"gmail_extra">
<br clear=3D"all">
<div>--<br>Christian Decker<br></div>
<br><br><div class=3D"gmail_quote">On Fri, Aug 8, 2014 at 11:26 AM, Wladimi=
r <span dir=3D"ltr"><<a href=3D"mailto:laanwj@gmail.com" target=3D"_blan=
k">laanwj@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>
<div class=3D"">On Fri, Aug 8, 2014 at 12:15 PM, Wladimir <<a href=3D"ma=
ilto:laanwj@gmail.com">laanwj@gmail.com</a>> wrote:<br>
> On Fri, Aug 8, 2014 at 12:01 PM, Mike Hearn <<a href=3D"mailto:mike=
@plan99.net">mike@plan99.net</a>> wrote:<br>
>>> He wants to use it to advertise services that are not part of =
the P2P<br>
>>> protocol itself, but run on a different port. Reserving servic=
es bits<br>
>>> for those is not acceptable.<br>
>><br>
>><br>
>> Why not? Does the port matter much?<br>
><br>
> Yes. The services bits are for advertising services on the P2P<br>
> network. That's not open for discussion.<br>
<br>
</div>It also wouldn't work. A bit is not enough to find an external se=
rvice<br>
except in the naive case where the advertised service would have a<br>
fixed port. Not even bitcoind has a fixed port. So there needs to be a<br>
mechanism to find how to connect to the 'external service'. This is=
<br>
provided by the proposed extension.<br>
<br>
It would in principle be possible to advertise an extra service bit<br>
*in addition to* this one, to make it easier to find through the addr<br>
mechanism. But it =C2=A0would be confusing and IMO an abuse of P2P service<=
br>
bits.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
Wladimir<br>
<br>
---------------------------------------------------------------------------=
---<br>
Want fast and easy access to all the code in your enterprise? Index and<br>
search up to 200,000 lines of code with a free copy of Black Duck<br>
Code Sight - the same software that powers the world's largest code<br>
search on Ohloh, the Black Duck Open Hub! Try it now.<br>
<a href=3D"http://p.sf.net/sfu/bds" target=3D"_blank">http://p.sf.net/sfu/b=
ds</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br></div>
--001a11330da805522005001bdc38--
|
