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
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <witchspace81@gmail.com>) id 1Qf6F2-00056N-V3
for bitcoin-development@lists.sourceforge.net;
Fri, 08 Jul 2011 08:16:52 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.47 as permitted sender)
client-ip=209.85.213.47; envelope-from=witchspace81@gmail.com;
helo=mail-yw0-f47.google.com;
Received: from mail-yw0-f47.google.com ([209.85.213.47])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Qf6F1-0005Ff-Rj
for bitcoin-development@lists.sourceforge.net;
Fri, 08 Jul 2011 08:16:52 +0000
Received: by ywa12 with SMTP id 12so895996ywa.34
for <bitcoin-development@lists.sourceforge.net>;
Fri, 08 Jul 2011 01:16:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.150.166.8 with SMTP id o8mr1651504ybe.414.1310113006367; Fri,
08 Jul 2011 01:16:46 -0700 (PDT)
Received: by 10.151.150.15 with HTTP; Fri, 8 Jul 2011 01:16:46 -0700 (PDT)
In-Reply-To: <4E16A567.6020309@justmoon.de>
References: <20110707111557.GA5231@ulyssis.org> <4E16A567.6020309@justmoon.de>
Date: Fri, 8 Jul 2011 08:16:46 +0000
Message-ID: <CAJNQ0st3ygLHPtq8fa9ceivSC1DQ38Hv+AQRiaXw=aL2Jze33Q@mail.gmail.com>
From: John Smith <witchspace81@gmail.com>
To: Stefan Thomas <moon@justmoon.de>
Content-Type: multipart/alternative; boundary=000e0cd47b4e5c343404a78a74ef
X-Spam-Score: -0.5 (/)
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
(witchspace81[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.1 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (witchspace81[at]gmail.com)
1.0 HTML_MESSAGE BODY: HTML included in message
-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: 1Qf6F1-0005Ff-Rj
Cc: bitcoin-development@lists.sourceforge.net
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 08:16:53 -0000
--000e0cd47b4e5c343404a78a74ef
Content-Type: text/plain; charset=ISO-8859-1
I agree. I think breaking compatiblity with older address (even testnet) is
not a
On Fri, Jul 8, 2011 at 6:36 AM, Stefan Thomas <moon@justmoon.de> wrote:
> 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?
> >
>
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--000e0cd47b4e5c343404a78a74ef
Content-Type: text/html; charset=ISO-8859-1
I agree. I think breaking compatiblity with older address (even testnet) is not a<br><br><div class="gmail_quote">On Fri, Jul 8, 2011 at 6:36 AM, Stefan Thomas <span dir="ltr"><<a href="mailto:moon@justmoon.de">moon@justmoon.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hey Pieter,<br>
<div class="im"><br>
> Otherwise, we could reset testnet (not actually reset, just<br>
> change its addresses a bit), and simply state odd=testnet, even=realnet.<br>
<br>
</div>We could use the XOR hack for now and remove it the next time we reset<br>
testnet. But I do think the 111 is baggage we want to get rid of. Using<br>
the lsb as a simple flag is much cleaner.<br>
<br>
Cheers,<br>
<font color="#888888"><br>
Stefan<br>
</font><div><div></div><div class="h5"><br>
<br>
On 7/7/2011 1:15 PM, Pieter Wuille wrote:<br>
> Hello everyone,<br>
><br>
> after a discussion on IRC, we decided to try to standardize the version bytes<br>
> used by bitcoin for several applications.<br>
><br>
> There are 3 components that seem meaningful:<br>
> * network? (realnet, testnet, alternate chains?)<br>
> * data class? (address, private key, master key, ...?)<br>
> * version? (real version, per data class defined)<br>
><br>
> There is no technical reason why different network and different data classes<br>
> would need separate version bytes, but i think it is a good thing to keep<br>
> them from colliding. People will mix them up, and when things are well<br>
> defined, a nice warning message could help a lot ("Oops it seems you entered<br>
> a private key instead of an address!").<br>
><br>
> So, first of all, there is already one actually used alternate chain, namely<br>
> namecoin, using version byte 52 for addresses. For this reason, i'd like to<br>
> reserve bit 16 in the version byte for "alternate chain". When bit 16 is set,<br>
> everything is up to the network itself, and no further semantics are defined.<br>
><br>
> When bit 16 isn't set:<br>
><br>
> Then remains the rest of the network. The problem is that testnet already uses<br>
> version 111, which is not a single bit. We can use a trick though, namely<br>
> choosing bit 1 for testnet, and if bit 1 is set, XOR the rest of the version<br>
> number with 111. Otherwise, we could reset testnet (not actually reset, just<br>
> change its addresses a bit), and simply state odd=testnet, even=realnet.<br>
><br>
> That leaves use with 6 more bits to play with, namely 128,64,32 and 8,4,2.<br>
> As 128 is already used for private keys, let's use (128,64,32) for data classes,<br>
> and (8,4,2) for versions.<br>
><br>
> So, in full:<br>
> * Bits 128/64/32 define data class<br>
> ** 0 = address<br>
> ** 32,64,96,160,192 = reserved for future use<br>
> ** 128 = private key<br>
> ** 224 = extended data class, another "data class" byte follows<br>
> * Bit 16 defines "private"<br>
> ** 0 = bitcoin<br>
> ** 16 = alternate chain<br>
> * Bits 8/4/2 define version number<br>
> ** 0 = only thing used for now<br>
> ** 2,4,6,8,10,12 = reserved for future use<br>
> ** 14 = extended version, another version byte follows<br>
> * Bit 1 defines testnet<br>
> ** 0 = realnet<br>
> ** 1 = testnet (possibly using XOR 111, if not reset)<br>
><br>
> This whole discussion started when Stefan wanted to define a format for master keys from which<br>
> to derive deterministic wallet keys, i suggest using data class 192 for that, leaving the<br>
> lower numbers for more basic data, like public keys.<br>
><br>
> Any comments?<br>
><br>
<br>
<br>
</div></div><div><div></div><div class="h5">------------------------------------------------------------------------------<br>
All of the data generated in your IT infrastructure is seriously valuable.<br>
Why? It contains a definitive record of application performance, security<br>
threats, fraudulent activity, and more. Splunk takes this data and makes<br>
sense of it. IT sense. And common sense.<br>
<a href="http://p.sf.net/sfu/splunk-d2d-c2" target="_blank">http://p.sf.net/sfu/splunk-d2d-c2</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
</div></div></blockquote></div><br>
--000e0cd47b4e5c343404a78a74ef--
|
