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
|
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 1QWjFJ-0001XH-A8
for bitcoin-development@lists.sourceforge.net;
Wed, 15 Jun 2011 06:06:33 +0000
X-ACL-Warn:
Received: from mail-iy0-f175.google.com ([209.85.210.175])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1QWjFI-0007z8-4h
for bitcoin-development@lists.sourceforge.net;
Wed, 15 Jun 2011 06:06:33 +0000
Received: by iye7 with SMTP id 7so23483iye.34
for <bitcoin-development@lists.sourceforge.net>;
Tue, 14 Jun 2011 23:06:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.84.3 with SMTP id h3mr103638ibl.109.1308117986761; Tue, 14
Jun 2011 23:06:26 -0700 (PDT)
Received: by 10.231.19.203 with HTTP; Tue, 14 Jun 2011 23:06:26 -0700 (PDT)
X-Originating-IP: [99.173.148.118]
Date: Wed, 15 Jun 2011 02:06:26 -0400
Message-ID: <BANLkTi=4UeK2D0cCHYGp1tHUTGA2iyWHcA@mail.gmail.com>
From: Jeff Garzik <jgarzik@exmulti.com>
To: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: 0.1 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.1 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1QWjFI-0007z8-4h
Subject: [Bitcoin-development] Protocol versioning
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, 15 Jun 2011 06:06:33 -0000
This issue has been simmering for a while...
I agree with the following general principles, and it sounds like
others on the forums do too:
GP1) Alternative implementations of a protocol are beneficial to the ecosystem.
GP2) Tying together protocol and client version is sub-optimal, and
undesirable long term.
The current, coarse-grained scheme was clearly preferred by satoshi.
He knew what a chore creating a fully compliant client would be, and
when I joined (July 2010), was actively discouraging alternative
client efforts. Also, tying protocol and client version together
certainly eased the deployment of changes.
Protocol development has clearly slowed, and we have at least one
major alternative client in the works (bitcoinj), so it seems fair to
revisit those assumptions and preferences.
Here are several mini-proposals for the Satoshi Client (anyone got a
better nickname?) along these lines, which should better prepare the
bitcoin protocol for the long term:
MP1) Avoid creating four-component version numbers (W.X.Y.Z), and use
pszSubVer as a client identification string. This proposal originally
came from Mike Hearn, IIRC.
MP2) remove IP transactions in v0.4
MP3) create constants for protocol version, and audit code to split
client version from protocol version. This is a THORNY patch, and far
more difficult than https://github.com/bitcoin/bitcoin/pull/63
implies. The code has various data structures and such versioned, so
it is difficult to pick out at quick glance which 'version' is which.
MP4) split protocol and client versions in v0.4 -- though you will not
actually notice a change until v0.4.1, when the client version changes
but the protocol version does not.
MP5) Use a single bit inside 'nServices' to indicate the presence of
an optional "capabilities" message. The purpose of this is to enable
minor protocol changes without having to change the protocol version.
Thus, nodes may advertise /features/ rather than simply "I support all
features >= version X". Most mature protocols support this sort of
thing, rather than the simpler, coarse-grained version number system.
--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti.com
|
