summaryrefslogtreecommitdiff
path: root/44/0a43541dfd7218fdd40e25eaaaff00fff092ad
blob: fe9e9f4900290c21cf29e2042164210116e56c9d (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
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <jgarzik@exmulti.com>) id 1SUith-00063F-LO
	for bitcoin-development@lists.sourceforge.net;
	Wed, 16 May 2012 18:24:29 +0000
X-ACL-Warn: 
Received: from mail-lpp01m010-f47.google.com ([209.85.215.47])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1SUitg-0007Fa-Ll
	for bitcoin-development@lists.sourceforge.net;
	Wed, 16 May 2012 18:24:29 +0000
Received: by lags15 with SMTP id s15so1035413lag.34
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 16 May 2012 11:24:20 -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:date:message-id:subject:from:to:cc
	:content-type:content-transfer-encoding:x-gm-message-state;
	bh=YWAixVpnF2OOpUQDOLfwvmtrIUlq+E8NNIRyoeb0ais=;
	b=Kx7GYKx/migPFIVW+jAcUxIarjtkZE9qcg4KI/Cn2gP4IFW71OBMHTHzv9vVaV7tSM
	KJ3ZL88Oe8zeUtfHjxhn3WEHgb/c65cFoR2wmpn1tPcI7DKX1hMuTqkN0oU9Yun5tBnu
	1OZKxbOpyTuibUAaryAcdU9dYuO/YMPa8ZmGL5V87Fdyl2dN358DAwlJtQqnEpCcICov
	+HHvtkvufV3HBusCeUVrU49T84F7bM1ZkYvsqEtTE7cXepWpUmNm3frtaOdjnTe7yZol
	H4tHkIPssc0Wb0/4M4/j/GK0tGxZ8EWoITk4fv0LIR985IFi0h498urWsVimSVAAVLjt
	RMfw==
MIME-Version: 1.0
Received: by 10.112.41.130 with SMTP id f2mr1032039lbl.5.1337192307624; Wed,
	16 May 2012 11:18:27 -0700 (PDT)
Received: by 10.114.25.97 with HTTP; Wed, 16 May 2012 11:18:27 -0700 (PDT)
X-Originating-IP: [99.43.178.25]
Date: Wed, 16 May 2012 14:18:27 -0400
Message-ID: <CA+8xBpd-0nXdda4fwyFonEY6rOSSyt=5goD-rbMTpvkcuHNTog@mail.gmail.com>
From: Jeff Garzik <jgarzik@exmulti.com>
To: Amir Taaki <zgenjix@yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQk/r9g+5JCPGJ2cPZ5m5J+diGimY7ZiUscZ3V5m+hKl25LQ2PYRE548pSzV4Gu2i+TGyA+F
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	0.0 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1SUitg-0007Fa-Ll
Cc: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Subject: [Bitcoin-development] P2P feature discovery (was Re: BIP 33 -
 Stratized Nodes)
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: Wed, 16 May 2012 18:24:29 -0000

On Wed, May 16, 2012 at 12:34 PM, Amir Taaki <zgenjix@yahoo.com> wrote:
> Please check out my proposal,
>
> https://en.bitcoin.it/wiki/BIP_0033
>
> I want to use the existing Bitcoin protocol to provide this functionality=
 in order to maintain compatibility. This proposal does not affect current =
Bitcoin clients, but allows the parallel system to operate alongside and so=
metimes intersect with the main Bitcoin network in a positive way.


I do not object to the concept, but the discovery process should be
improved.  Even venerable SMTP has a better, more flexible
capabilities discovery process.

Instead of further overloading service bits in the version message, or
altering the version message, let us instead make feature discovery an
easy, flexible, extensible process.

We can add new commands without impacting older nodes, so let's create
a new command "get-features" (or pick your name) that returns a list
of key/value pairs.  The key is a string, the value type is determined
by the key.

Standard behavior of clients would be to send "get-features" after
seeing remote version info, as part of the initial connection
handshake.

In any case, the basic point is to move FAR away from fighting over a
limited, inflexible resource (service bits in "version" msg) to
something string-based and easily extensible.

I can create this as BIP 34, if people wish.

--=20
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti.com