summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorStefan Thomas <moon@justmoon.de>2011-07-08 08:36:23 +0200
committerbitcoindev <bitcoindev@gnusha.org>2011-07-08 06:41:14 +0000
commit819952336d367cfcdd8383445bd69c5a5209d9f6 (patch)
treebcaf06a58a4963f83d995d259ce1ff0b616d9ff7
parentc30efefd1e39f3efddb679bd48820b384599a126 (diff)
downloadpi-bitcoindev-819952336d367cfcdd8383445bd69c5a5209d9f6.tar.gz
pi-bitcoindev-819952336d367cfcdd8383445bd69c5a5209d9f6.zip
Re: [Bitcoin-development] Version bytes
-rw-r--r--c1/4c47157dd3b1516acb3ceacda095bea6dc8758120
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?
+>
+
+
+