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; 
MIME-Version: 1.0
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
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Version bytes
Precedence: list

--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">&lt;<a href="mailto:moon@justmoon.de">moon@justmoon.de</a>&gt;</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>
&gt; Otherwise, we could reset testnet (not actually reset, just<br>
&gt; 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>
&gt; Hello everyone,<br>
&gt;<br>
&gt; after a discussion on IRC, we decided to try to standardize the version bytes<br>
&gt; used by bitcoin for several applications.<br>
&gt;<br>
&gt; There are 3 components that seem meaningful:<br>
&gt; * network? (realnet, testnet, alternate chains?)<br>
&gt; * data class? (address, private key, master key, ...?)<br>
&gt; * version? (real version, per data class defined)<br>
&gt;<br>
&gt; There is no technical reason why different network and different data classes<br>
&gt; would need separate version bytes, but i think it is a good thing to keep<br>
&gt; them from colliding. People will mix them up, and when things are well<br>
&gt; defined, a nice warning message could help a lot (&quot;Oops it seems you entered<br>
&gt; a private key instead of an address!&quot;).<br>
&gt;<br>
&gt; So, first of all, there is already one actually used alternate chain, namely<br>
&gt; namecoin, using version byte 52 for addresses. For this reason, i&#39;d like to<br>
&gt; reserve bit 16 in the version byte for &quot;alternate chain&quot;. When bit 16 is set,<br>
&gt; everything is up to the network itself, and no further semantics are defined.<br>
&gt;<br>
&gt; When bit 16 isn&#39;t set:<br>
&gt;<br>
&gt; Then remains the rest of the network. The problem is that testnet already uses<br>
&gt; version 111, which is not a single bit. We can use a trick though, namely<br>
&gt; choosing bit 1 for testnet, and if bit 1 is set, XOR the rest of the version<br>
&gt; number with 111. Otherwise, we could reset testnet (not actually reset, just<br>
&gt; change its addresses a bit), and simply state odd=testnet, even=realnet.<br>
&gt;<br>
&gt; That leaves use with 6 more bits to play with, namely 128,64,32 and 8,4,2.<br>
&gt; As 128 is already used for private keys, let&#39;s use (128,64,32) for data classes,<br>
&gt; and (8,4,2) for versions.<br>
&gt;<br>
&gt; So, in full:<br>
&gt; * Bits 128/64/32 define data class<br>
&gt; ** 0 = address<br>
&gt; ** 32,64,96,160,192 = reserved for future use<br>
&gt; ** 128 = private key<br>
&gt; ** 224 = extended data class, another &quot;data class&quot; byte follows<br>
&gt; * Bit 16 defines &quot;private&quot;<br>
&gt; ** 0 = bitcoin<br>
&gt; ** 16 = alternate chain<br>
&gt; * Bits 8/4/2 define version number<br>
&gt; ** 0 = only thing used for now<br>
&gt; ** 2,4,6,8,10,12 = reserved for future use<br>
&gt; ** 14 = extended version, another version byte follows<br>
&gt; * Bit 1 defines testnet<br>
&gt; ** 0 = realnet<br>
&gt; ** 1 = testnet (possibly using XOR 111, if not reset)<br>
&gt;<br>
&gt; This whole discussion started when Stefan wanted to define a format for master keys from which<br>
&gt; to derive deterministic wallet keys, i suggest using data class 192 for that, leaving the<br>
&gt; lower numbers for more basic data, like public keys.<br>
&gt;<br>
&gt; Any comments?<br>
&gt;<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--