sipa made a nice specification for version numbers a while back, that seemed great at the time. However, there are concerns that it has overlooked a very important factor: usability in base58 encoding. The version currently chosen for script-based addresses (2) makes this excessively complicated for end users-- these addresses, once encoded, may begin with ANY of the following characters: 2opqrstuvwxyz
Taking this into account, as well as sipa's original goals, I have come up with the following proposal: * Bits 128/64 define network class ** 0 = main network ** 64,128 = reserved ** 192 = test network * Bits 32/16 define network ** 0 = Bitcoin ** 16,32 = reserved ** 48 = OTHER (next octet) * Bits 8/4/2 define data class ** 0 = Public key hash ** 2 = Public key (raw) ** 4 = Script hash ** 6 = reserved ** 8 = Private key (raw) ** 10 = Signature ** 12 = reserved ** 14 = OTHER (next octet) * Bit 1 is freely chosen (for aesthetic assignment) Unlike sipa's proposal, however, I have (intentionally) neglected to consider the versions currently in use other than the widespread Bitcoin addresses. That means this reassigns the versions used by Namecoin and testnets, and probably messes with the (unmerged) key export format and signature formats. It "wastes" 2 bits (64 and 1) to accomplish aesthetic norms. Bit 64 *could* be assigned in the future if we ever have a "crunch". By using the high bit (128) to designate test networks, all testnet addresses will now begin with '2'. Bitcoin script-hash (aka OP_EVAL) addresses are assigned version 5 (using the aesthetic +1), which means they always begin with '3'. Signatures are on version 10 and/or 11, beginning with '5'. We get two first-class "networks" besides Bitcoin, addresses starting with '7' and 'E' (pubkey), and '9' and 'F' (script). I propose these should be assigned sparingly, only when a network has significant adoption-- the only one I would even *consider* might fit the requirement today is Namecoin. I would also suggest making merged mining support a requirement except for networks that have a proven-better proof-of-work (ie, NOT scrypt). Other networks can use the "other" value (thus beginning with 'L' and 'N') and a second octet (which can be divided up later). Thoughts? Luke ------------------------------------------------------------------------------ Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
