public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Luke-Jr" <luke@dashjr.org>
To: bitcoin-development@lists.sourceforge.net
Subject: [Bitcoin-development] Version bytes "2.0"
Date: Tue, 6 Dec 2011 16:10:39 -0500	[thread overview]
Message-ID: <201112061610.41083.luke@dashjr.org> (raw)

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



             reply	other threads:[~2011-12-06 21:10 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-06 21:10 Luke-Jr [this message]
2011-12-06 21:28 ` [Bitcoin-development] Version bytes "2.0" Luke-Jr
2011-12-10 18:16   ` Luke-Jr
     [not found]     ` <20111212205559.GA16665@ulyssis.org>
2011-12-12 20:57       ` Pieter Wuille
2011-12-12 21:02       ` Luke-Jr
2011-12-13 10:38         ` Mike Hearn
2011-12-13 10:56           ` Wladimir
2011-12-13 11:07             ` Mike Hearn
2011-12-13 11:15               ` Wladimir
2011-12-13 15:43               ` Luke-Jr

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201112061610.41083.luke@dashjr.org \
    --to=luke@dashjr.org \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox