From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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? >