diff options
author | Stefan Thomas <moon@justmoon.de> | 2011-07-08 08:36:23 +0200 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2011-07-08 06:41:14 +0000 |
commit | 819952336d367cfcdd8383445bd69c5a5209d9f6 (patch) | |
tree | bcaf06a58a4963f83d995d259ce1ff0b616d9ff7 | |
parent | c30efefd1e39f3efddb679bd48820b384599a126 (diff) | |
download | pi-bitcoindev-819952336d367cfcdd8383445bd69c5a5209d9f6.tar.gz pi-bitcoindev-819952336d367cfcdd8383445bd69c5a5209d9f6.zip |
Re: [Bitcoin-development] Version bytes
-rw-r--r-- | c1/4c47157dd3b1516acb3ceacda095bea6dc8758 | 120 |
1 files changed, 120 insertions, 0 deletions
diff --git a/c1/4c47157dd3b1516acb3ceacda095bea6dc8758 b/c1/4c47157dd3b1516acb3ceacda095bea6dc8758 new file mode 100644 index 000000000..ebf9f334a --- /dev/null +++ b/c1/4c47157dd3b1516acb3ceacda095bea6dc8758 @@ -0,0 +1,120 @@ +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 <moon@justmoon.de>) 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 <moon@justmoon.de> +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: <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 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? +> + + + |