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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jgarzik@exmulti.com>) id 1T0vZc-0002Eq-Vj
for bitcoin-development@lists.sourceforge.net;
Mon, 13 Aug 2012 14:24:52 +0000
X-ACL-Warn:
Received: from mail-qc0-f175.google.com ([209.85.216.175])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1T0vZX-0007RH-C3
for bitcoin-development@lists.sourceforge.net;
Mon, 13 Aug 2012 14:24:52 +0000
Received: by qcad10 with SMTP id d10so2316128qca.34
for <bitcoin-development@lists.sourceforge.net>;
Mon, 13 Aug 2012 07:24:41 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20120113;
h=mime-version:x-originating-ip:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type:x-gm-message-state;
bh=fpWftmJyXv4EBhcp+QEwRWh1CO5gulgp1AXzrwfkaSM=;
b=fLTFzj4sqc2ULuMewes+fdJKY77GpsA5V7XGSZoGUEHwvI5JosEodqxJXr4K3up3Jq
amKRivAUmHIGj+vzHyRFfbPXNcX0pQFr1jVU+LkO2iXMCK/gpu9Yx7P4L0gUlwn4Qia/
vK/nNXDL/Q8av5SVsQJZEBbBEmfE5ycG5gjCfKvdayHhNsQHgMdselyu4VCx/zIRsdN9
wUgis9e9VR6SthYGxpBS9lw8RxQYw7T50x+rojHevReaZ8BnzAEpkrRTWtT22KvVzh3w
8t4jr0jT3knMajvPifjCHyaS6Orqr1k05PeDUnazyl3ghjzKWTwrk1mn/F/XZUi73xNe
ZMZA==
MIME-Version: 1.0
Received: by 10.224.0.202 with SMTP id 10mr25489773qac.5.1344867881836; Mon,
13 Aug 2012 07:24:41 -0700 (PDT)
Received: by 10.49.35.195 with HTTP; Mon, 13 Aug 2012 07:24:41 -0700 (PDT)
X-Originating-IP: [2001:4830:1603:2:21c:c0ff:fe79:c8c2]
In-Reply-To: <5028AFBE.8070104@justmoon.de>
References: <5028AFBE.8070104@justmoon.de>
Date: Mon, 13 Aug 2012 10:24:41 -0400
Message-ID: <CA+8xBpfZzxBgqO6xT6+a_ACgYR=3cV9rmY_kmSovtT3dfjdhDg@mail.gmail.com>
From: Jeff Garzik <jgarzik@exmulti.com>
To: Stefan Thomas <moon@justmoon.de>
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQkopwyOO4cBkFsvYEncr1jQroqmOYvGsbT+OgwQy8Bg4IolvIpTV1SvCZusT802aE0aIFNW
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1T0vZX-0007RH-C3
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] BIP: Custom 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: Mon, 13 Aug 2012 14:24:53 -0000
On Mon, Aug 13, 2012 at 3:41 AM, Stefan Thomas <moon@justmoon.de> wrote:
> I was working on some custom protocol extensions for Bitcoin that I
> wanted to experiment with and I noticed that in order to enable nodes to
> announce these services the only mechanism the protocol currently
> provides is to use one of the 64 bits of the services field. This is
> obviously a resource that will run out quickly if we all just help
> ourselves, so I set out to come up with a standardized way to announce
> custom protocol extensions, without using up NODE_* flags.
>
> Please kindly review my solution:
>
> https://en.bitcoin.it/wiki/User:Justmoon/BIP_Draft:_Custom_Services
heh, this is not a new idea. I even implemented a pull request for
service discovery myself, which simply consisted of querying the list
of supported commands:
https://github.com/bitcoin/bitcoin/pull/1471
On IRC, I proposed several alternatives including modifying 'version'
(which you did) and a new "getcaps" (get capabilities) command to be
added in protocol_version X.
gmaxwell seems continually unenthused, and made a valid point about
service advertisement: these capabilities are not advertised with
CAddress, so how does one usefully discover and make use of them?
What are real world use cases, that cannot be solved with nService
bits?
My only response is a weak one: inevitability. It seems likely that
-somebody- will implement their own P2P commands for their own client
subset, even if only a simple "use 'getstatus' with strSubVer matching
/FooClient/"
Therefore, if it is inevitable, we might as well make some basic rules
about how to extended your P2P command set.
--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti.com
|
