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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <luke@dashjr.org>) id 1RY2Hv-00078t-2u
for bitcoin-development@lists.sourceforge.net;
Tue, 06 Dec 2011 21:10:55 +0000
X-ACL-Warn:
Received: from zinan.dashjr.org ([173.242.112.54])
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1RY2Hs-0000jC-2n for bitcoin-development@lists.sourceforge.net;
Tue, 06 Dec 2011 21:10:55 +0000
Received: from ishibashi.localnet (fl-184-4-160-40.dhcp.embarqhsd.net
[184.4.160.40]) (Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 7EA5A56201C
for <bitcoin-development@lists.sourceforge.net>;
Tue, 6 Dec 2011 21:10:46 +0000 (UTC)
From: "Luke-Jr" <luke@dashjr.org>
To: bitcoin-development@lists.sourceforge.net
Date: Tue, 6 Dec 2011 16:10:39 -0500
User-Agent: KMail/1.13.7 (Linux/3.1.0-gentoo; KDE/4.6.5; x86_64; ; )
X-PGP-Key-Fingerprint: CE5A D56A 36CC 69FA E7D2 3558 665F C11D D53E 9583
X-PGP-Key-ID: 665FC11DD53E9583
X-PGP-Keyserver: x-hkp://subkeys.pgp.net
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <201112061610.41083.luke@dashjr.org>
X-Spam-Score: -1.2 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1RY2Hs-0000jC-2n
Subject: [Bitcoin-development] Version bytes "2.0"
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, 06 Dec 2011 21:10:55 -0000
sipa made a nice specification for version numbers a while back, that seemed
great at the time. However, there are concerns that it has overlooked a very
important factor: usability in base58 encoding. The version currently chosen
for script-based addresses (2) makes this excessively complicated for end
users-- these addresses, once encoded, may begin with ANY of the following
characters: 2opqrstuvwxyz
Taking this into account, as well as sipa's original goals, I have come up
with the following proposal:
* Bits 128/64 define network class
** 0 = main network
** 64,128 = reserved
** 192 = test network
* Bits 32/16 define network
** 0 = Bitcoin
** 16,32 = reserved
** 48 = OTHER (next octet)
* Bits 8/4/2 define data class
** 0 = Public key hash
** 2 = Public key (raw)
** 4 = Script hash
** 6 = reserved
** 8 = Private key (raw)
** 10 = Signature
** 12 = reserved
** 14 = OTHER (next octet)
* Bit 1 is freely chosen (for aesthetic assignment)
Unlike sipa's proposal, however, I have (intentionally) neglected to consider
the versions currently in use other than the widespread Bitcoin addresses.
That means this reassigns the versions used by Namecoin and testnets, and
probably messes with the (unmerged) key export format and signature formats.
It "wastes" 2 bits (64 and 1) to accomplish aesthetic norms. Bit 64 *could* be
assigned in the future if we ever have a "crunch". By using the high bit (128)
to designate test networks, all testnet addresses will now begin with '2'.
Bitcoin script-hash (aka OP_EVAL) addresses are assigned version 5 (using the
aesthetic +1), which means they always begin with '3'. Signatures are on
version 10 and/or 11, beginning with '5'.
We get two first-class "networks" besides Bitcoin, addresses starting with '7'
and 'E' (pubkey), and '9' and 'F' (script). I propose these should be assigned
sparingly, only when a network has significant adoption-- the only one I would
even *consider* might fit the requirement today is Namecoin. I would also
suggest making merged mining support a requirement except for networks that
have a proven-better proof-of-work (ie, NOT scrypt). Other networks can use
the "other" value (thus beginning with 'L' and 'N') and a second octet (which
can be divided up later).
Thoughts?
Luke
|
