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
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <moon@justmoon.de>) id 1Qf4kU-0004f4-0w
for bitcoin-development@lists.sourceforge.net;
Fri, 08 Jul 2011 06:41:14 +0000
X-ACL-Warn:
Received: from sulfur.webpack.hosteurope.de ([217.115.142.104])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Qf4kS-0000PZ-Cs for bitcoin-development@lists.sourceforge.net;
Fri, 08 Jul 2011 06:41:13 +0000
Received: from 84-72-69-153.dclient.hispeed.ch ([84.72.69.153]
helo=[192.168.0.18]); authenticated
by sulfur.webpack.hosteurope.de running ExIM with esmtpsa
(TLSv1:AES256-SHA:256)
id 1Qf4kM-0007Qg-8e; Fri, 08 Jul 2011 08:41:06 +0200
Message-ID: <4E16A567.6020309@justmoon.de>
Date: Fri, 08 Jul 2011 08:36:23 +0200
From: Stefan Thomas <moon@justmoon.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <20110707111557.GA5231@ulyssis.org>
In-Reply-To: <20110707111557.GA5231@ulyssis.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-bounce-key: webpack.hosteurope.de;moon@justmoon.de;1310107272;ecf93b2b;
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: 1Qf4kS-0000PZ-Cs
Subject: Re: [Bitcoin-development] Version bytes
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: Fri, 08 Jul 2011 06:41:14 -0000
Hey Pieter,
> Otherwise, we could reset testnet (not actually reset, just
> change its addresses a bit), and simply state odd=testnet, even=realnet.
We could use the XOR hack for now and remove it the next time we reset
testnet. But I do think the 111 is baggage we want to get rid of. Using
the lsb as a simple flag is much cleaner.
Cheers,
Stefan
On 7/7/2011 1:15 PM, Pieter Wuille wrote:
> Hello everyone,
>
> after a discussion on IRC, we decided to try to standardize the version bytes
> used by bitcoin for several applications.
>
> There are 3 components that seem meaningful:
> * network? (realnet, testnet, alternate chains?)
> * data class? (address, private key, master key, ...?)
> * version? (real version, per data class defined)
>
> There is no technical reason why different network and different data classes
> would need separate version bytes, but i think it is a good thing to keep
> them from colliding. People will mix them up, and when things are well
> defined, a nice warning message could help a lot ("Oops it seems you entered
> a private key instead of an address!").
>
> So, first of all, there is already one actually used alternate chain, namely
> namecoin, using version byte 52 for addresses. For this reason, i'd like to
> reserve bit 16 in the version byte for "alternate chain". When bit 16 is set,
> everything is up to the network itself, and no further semantics are defined.
>
> When bit 16 isn't set:
>
> Then remains the rest of the network. The problem is that testnet already uses
> version 111, which is not a single bit. We can use a trick though, namely
> choosing bit 1 for testnet, and if bit 1 is set, XOR the rest of the version
> number with 111. Otherwise, we could reset testnet (not actually reset, just
> change its addresses a bit), and simply state odd=testnet, even=realnet.
>
> That leaves use with 6 more bits to play with, namely 128,64,32 and 8,4,2.
> As 128 is already used for private keys, let's use (128,64,32) for data classes,
> and (8,4,2) for versions.
>
> So, in full:
> * Bits 128/64/32 define data class
> ** 0 = address
> ** 32,64,96,160,192 = reserved for future use
> ** 128 = private key
> ** 224 = extended data class, another "data class" byte follows
> * Bit 16 defines "private"
> ** 0 = bitcoin
> ** 16 = alternate chain
> * Bits 8/4/2 define version number
> ** 0 = only thing used for now
> ** 2,4,6,8,10,12 = reserved for future use
> ** 14 = extended version, another version byte follows
> * Bit 1 defines testnet
> ** 0 = realnet
> ** 1 = testnet (possibly using XOR 111, if not reset)
>
> This whole discussion started when Stefan wanted to define a format for master keys from which
> to derive deterministic wallet keys, i suggest using data class 192 for that, leaving the
> lower numbers for more basic data, like public keys.
>
> Any comments?
>
|
