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 ) 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 ; 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: From: John Smith To: Stefan Thomas 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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

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--