summaryrefslogtreecommitdiff
path: root/85/59d60eb8d921101c551e17191b3f8cdaba3b85
blob: c044c23ceaa50c1ecc6e555c1877e40f846cbb5b (plain)
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
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <laanwj@gmail.com>) id 1WwoYq-0004JF-VD
	for bitcoin-development@lists.sourceforge.net;
	Tue, 17 Jun 2014 08:16:08 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.223.176 as permitted sender)
	client-ip=209.85.223.176; envelope-from=laanwj@gmail.com;
	helo=mail-ie0-f176.google.com; 
Received: from mail-ie0-f176.google.com ([209.85.223.176])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WwoYp-0007uW-4J
	for bitcoin-development@lists.sourceforge.net;
	Tue, 17 Jun 2014 08:16:08 +0000
Received: by mail-ie0-f176.google.com with SMTP id rd18so6030880iec.21
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 17 Jun 2014 01:16:01 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.43.125.199 with SMTP id gt7mr909416icc.70.1402992961288;
	Tue, 17 Jun 2014 01:16:01 -0700 (PDT)
Received: by 10.64.60.195 with HTTP; Tue, 17 Jun 2014 01:16:01 -0700 (PDT)
In-Reply-To: <CA+s+GJBJ5aXNEv+8zARXHPL1+fg1Etd3-EhF2TeW+gS-_r+s3g@mail.gmail.com>
References: <20140617072351.GA7205@savin>
	<CA+s+GJAgQAZzwgONbD==fYTsV9jWKCZ6+gTiwohUT_H5kT_MoA@mail.gmail.com>
	<2024964.4FECq06JhC@crushinator>
	<CA+s+GJBJ5aXNEv+8zARXHPL1+fg1Etd3-EhF2TeW+gS-_r+s3g@mail.gmail.com>
Date: Tue, 17 Jun 2014 10:16:01 +0200
Message-ID: <CA+s+GJB_zpgth4=7O2vAOH2RPTz=9xZtbWH=dr6hYzDm8osNyw@mail.gmail.com>
From: Wladimir <laanwj@gmail.com>
To: Matt Whitlock <bip@mattwhitlock.name>
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(laanwj[at]gmail.com)
	-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: 1WwoYp-0007uW-4J
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal: allocate 8 service bits for
 experimental use
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: Tue, 17 Jun 2014 08:16:09 -0000

On Tue, Jun 17, 2014 at 10:08 AM, Wladimir <laanwj@gmail.com> wrote:
> On Tue, Jun 17, 2014 at 10:02 AM, Matt Whitlock <bip@mattwhitlock.name> wrote:
>> On Tuesday, 17 June 2014, at 9:57 am, Wladimir wrote:
>>> Yes, as I said in the github topic
>>> (https://github.com/bitcoin/bitcoin/pull/4351) I suggest we adapt a
>>> string-based name space for extensions.
>>
>> Why use textual strings? These fields are not for human consumption. Why not use UUIDs, which are fixed length and will not waste as much bandwidth in the protocol? Or if you'd prefer a hierarchical namespace, you could use OIDs, a la ASN.1.

Also it IS useful for these fields to be human readable for
statistics, peer list views and such. When encountering a new, unknown
extension when connecting to a node it's much more useful to get a
google-able string to find out what it is about, than some long
hexadecimal or dotted-number identifier.

Wladimir