From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1QemZ2-0004u1-9I for bitcoin-development@lists.sourceforge.net; Thu, 07 Jul 2011 11:16:12 +0000 X-ACL-Warn: Received: from rhcavuit01.kulnet.kuleuven.be ([134.58.240.129] helo=cavuit01.kulnet.kuleuven.be) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1QemZ0-00016z-0I for bitcoin-development@lists.sourceforge.net; Thu, 07 Jul 2011 11:16:12 +0000 X-KULeuven-Envelope-From: sipa@ulyssis.org X-Spam-Status: not spam, SpamAssassin (not cached, score=-48.788, required 5, autolearn=disabled, DKIM_ADSP_CUSTOM_MED 0.00, FREEMAIL_FROM 0.00, KUL_SMTPS -50.00, NML_ADSP_CUSTOM_MED 1.20, T_TO_NO_BRKTS_FREEMAIL 0.01) X-KULeuven-Scanned: Found to be clean X-KULeuven-ID: 7ECD41382BA.A679C X-KULeuven-Information: Katholieke Universiteit Leuven Received: from smtps01.kuleuven.be (smtpshost01.kulnet.kuleuven.be [134.58.240.74]) by cavuit01.kulnet.kuleuven.be (Postfix) with ESMTP id 7ECD41382BA for ; Thu, 7 Jul 2011 13:15:58 +0200 (CEST) Received: from smtp.ulyssis.org (mail.ulyssis.student.kuleuven.be [193.190.253.235]) by smtps01.kuleuven.be (Postfix) with ESMTP id 319D031E703 for ; Thu, 7 Jul 2011 13:15:58 +0200 (CEST) Received: from wop.ulyssis.org (wop.intern.ulyssis.org [192.168.0.182]) by smtp.ulyssis.org (Postfix) with ESMTP id 9CB7510067 for ; Thu, 7 Jul 2011 13:17:15 +0200 (CEST) Received: by wop.ulyssis.org (Postfix, from userid 615) id 48DE687C1AC; Thu, 7 Jul 2011 13:15:58 +0200 (CEST) Date: Thu, 7 Jul 2011 13:15:58 +0200 X-Kuleuven: This mail passed the K.U.Leuven mailcluster From: Pieter Wuille To: bitcoin-development@lists.sourceforge.net Message-ID: <20110707111557.GA5231@ulyssis.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-PGP-Key: http://sipa.ulyssis.org/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: 1.2 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (pieter.wuille[at]gmail.com) 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is CUSTOM_MED 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit, and not from a mailing list 0.0 T_TO_NO_BRKTS_FREEMAIL To: misformatted and free email service -0.0 AWL AWL: From: address is in the auto white-list X-Headers-End: 1QemZ0-00016z-0I Subject: [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: Thu, 07 Jul 2011 11:16:12 -0000 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? -- Pieter