[Bitcoin-development] Version bytes "2.0"

[Bitcoin-development] Version bytes "2.0"

[Luke-Jr]

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

Re: [Bitcoin-development] Version bytes "2.0"

[Luke-Jr]

Some bugs I found in my spec so far:
- Bitcoin public keys begin with '2' (same as testnet data)
- For the first first-class "aux" network, signatures and private keys will
  start with the same character.
- More "collisions" are possible if the "reserved" values were ever assigned.

To address these slightly better, here's a revised 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 = reserved
** 4 = Script hash
** 6 = Public key (raw)
** 8 = Signature
** 10 = reserved
** 12 = Private key (raw)
** 14 = OTHER (next octet)
* Bit 1 is freely chosen (for aesthetic assignment)

Note that under this scheme, both script hashes and raw public keys begin with 
'3'; I consider this a non-issue since neither are supported by current-
generation clients, and both pubkey-hash and script-hash are quite capable of 
the same functionality as a raw public key. Also, the raw public key will 
presumably be noticably longer.

For reference, a table of version number to first-base58-char mappings:
+........   0 => 1
-.......1   1 => QRSTUVWXYZabcdefghijkmno
-......1.   2 => 2opqrstuvwxyz
+......11   3 => 2
-.....1..   4 => 23
+.....1.1   5 => 3
+.....11.   6 => 3
-.....111   7 => 34
+....1...   8 => 4
-....1..1   9 => 45
+....1.1.  10 => 5
+....1.11  11 => 5
-....11..  12 => 56
+....11.1  13 => 6
-....111.  14 => 67
+....1111  15 => 7
+...1....  16 => 7
-...1...1  17 => 78
+...1..1.  18 => 8
-...1..11  19 => 89
+...1.1..  20 => 9
+...1.1.1  21 => 9
-...1.11.  22 => 9A
+...1.111  23 => A
-...11...  24 => AB
+...11..1  25 => B
+...11.1.  26 => B
-...11.11  27 => BC
+...111..  28 => C
-...111.1  29 => CD
+...1111.  30 => D
+...11111  31 => D
-..1.....  32 => DE
+..1....1  33 => E
-..1...1.  34 => EF
+..1...11  35 => F
+..1..1..  36 => F
-..1..1.1  37 => FG
+..1..11.  38 => G
-..1..111  39 => GH
+..1.1...  40 => H
+..1.1..1  41 => H
-..1.1.1.  42 => HJ
+..1.1.11  43 => J
-..1.11..  44 => JK
+..1.11.1  45 => K
+..1.111.  46 => K
-..1.1111  47 => KL
+..11....  48 => L
-..11...1  49 => LM
+..11..1.  50 => M
+..11..11  51 => M
-..11.1..  52 => MN
+..11.1.1  53 => N
-..11.11.  54 => NP
+..11.111  55 => P
+..111...  56 => P
-..111..1  57 => PQ
+..111.1.  58 => Q
-..111.11  59 => QR
+..1111..  60 => R
+..1111.1  61 => R
-..11111.  62 => RS
+..111111  63 => S
-.1......  64 => ST
+.1.....1  65 => T
+.1....1.  66 => T
-.1....11  67 => TU
+.1...1..  68 => U
-.1...1.1  69 => UV
+.1...11.  70 => V
+.1...111  71 => V
-.1..1...  72 => VW
+.1..1..1  73 => W
-.1..1.1.  74 => WX
+.1..1.11  75 => X
+.1..11..  76 => X
-.1..11.1  77 => XY
+.1..111.  78 => Y
-.1..1111  79 => YZ
+.1.1....  80 => Z
+.1.1...1  81 => Z
-.1.1..1.  82 => Za
+.1.1..11  83 => a
-.1.1.1..  84 => ab
+.1.1.1.1  85 => b
-.1.1.11.  86 => bc
+.1.1.111  87 => c
+.1.11...  88 => c
-.1.11..1  89 => cd
+.1.11.1.  90 => d
-.1.11.11  91 => de
+.1.111..  92 => e
+.1.111.1  93 => e
-.1.1111.  94 => ef
+.1.11111  95 => f
-.11.....  96 => fg
+.11....1  97 => g
+.11...1.  98 => g
-.11...11  99 => gh
+.11..1.. 100 => h
-.11..1.1 101 => hi
+.11..11. 102 => i
+.11..111 103 => i
-.11.1... 104 => ij
+.11.1..1 105 => j
-.11.1.1. 106 => jk
+.11.1.11 107 => k
+.11.11.. 108 => k
-.11.11.1 109 => km
+.11.111. 110 => m
-.11.1111 111 => mn
+.111.... 112 => n
+.111...1 113 => n
-.111..1. 114 => no
+.111..11 115 => o
-.111.1.. 116 => op
+.111.1.1 117 => p
+.111.11. 118 => p
-.111.111 119 => pq
+.1111... 120 => q
-.1111..1 121 => qr
+.1111.1. 122 => r
+.1111.11 123 => r
-.11111.. 124 => rs
+.11111.1 125 => s
-.111111. 126 => st
+.1111111 127 => t
+1....... 128 => t
-1......1 129 => tu
+1.....1. 130 => u
-1.....11 131 => uv
+1....1.. 132 => v
+1....1.1 133 => v
-1....11. 134 => vw
+1....111 135 => w
-1...1... 136 => wx
+1...1..1 137 => x
+1...1.1. 138 => x
-1...1.11 139 => xy
+1...11.. 140 => y
-1...11.1 141 => yz
+1...111. 142 => z
+1...1111 143 => z
-1..1.... 144 => 2z
+1..1...1 145 => 2
+1..1..1. 146 => 2
+1..1..11 147 => 2
+1..1.1.. 148 => 2
+1..1.1.1 149 => 2
+1..1.11. 150 => 2
+1..1.111 151 => 2
+1..11... 152 => 2
+1..11..1 153 => 2
+1..11.1. 154 => 2
+1..11.11 155 => 2
+1..111.. 156 => 2
+1..111.1 157 => 2
+1..1111. 158 => 2
+1..11111 159 => 2
+1.1..... 160 => 2
+1.1....1 161 => 2
+1.1...1. 162 => 2
+1.1...11 163 => 2
+1.1..1.. 164 => 2
+1.1..1.1 165 => 2
+1.1..11. 166 => 2
+1.1..111 167 => 2
+1.1.1... 168 => 2
+1.1.1..1 169 => 2
+1.1.1.1. 170 => 2
+1.1.1.11 171 => 2
+1.1.11.. 172 => 2
+1.1.11.1 173 => 2
+1.1.111. 174 => 2
+1.1.1111 175 => 2
+1.11.... 176 => 2
+1.11...1 177 => 2
+1.11..1. 178 => 2
+1.11..11 179 => 2
+1.11.1.. 180 => 2
+1.11.1.1 181 => 2
+1.11.11. 182 => 2
+1.11.111 183 => 2
+1.111... 184 => 2
+1.111..1 185 => 2
+1.111.1. 186 => 2
+1.111.11 187 => 2
+1.1111.. 188 => 2
+1.1111.1 189 => 2
+1.11111. 190 => 2
+1.111111 191 => 2
+11...... 192 => 2
+11.....1 193 => 2
+11....1. 194 => 2
+11....11 195 => 2
+11...1.. 196 => 2
+11...1.1 197 => 2
+11...11. 198 => 2
+11...111 199 => 2
+11..1... 200 => 2
+11..1..1 201 => 2
+11..1.1. 202 => 2
+11..1.11 203 => 2
+11..11.. 204 => 2
+11..11.1 205 => 2
+11..111. 206 => 2
+11..1111 207 => 2
+11.1.... 208 => 2
+11.1...1 209 => 2
+11.1..1. 210 => 2
+11.1..11 211 => 2
+11.1.1.. 212 => 2
+11.1.1.1 213 => 2
+11.1.11. 214 => 2
+11.1.111 215 => 2
+11.11... 216 => 2
+11.11..1 217 => 2
+11.11.1. 218 => 2
+11.11.11 219 => 2
+11.111.. 220 => 2
+11.111.1 221 => 2
+11.1111. 222 => 2
+11.11111 223 => 2
+111..... 224 => 2
+111....1 225 => 2
+111...1. 226 => 2
+111...11 227 => 2
+111..1.. 228 => 2
+111..1.1 229 => 2
+111..11. 230 => 2
+111..111 231 => 2
+111.1... 232 => 2
+111.1..1 233 => 2
+111.1.1. 234 => 2
+111.1.11 235 => 2
+111.11.. 236 => 2
+111.11.1 237 => 2
+111.111. 238 => 2
+111.1111 239 => 2
+1111.... 240 => 2
+1111...1 241 => 2
+1111..1. 242 => 2
+1111..11 243 => 2
+1111.1.. 244 => 2
+1111.1.1 245 => 2
+1111.11. 246 => 2
+1111.111 247 => 2
+11111... 248 => 2
+11111..1 249 => 2
+11111.1. 250 => 2
+11111.11 251 => 2
+111111.. 252 => 2
+111111.1 253 => 2
+1111111. 254 => 2
+11111111 255 => 2

Re: [Bitcoin-development] Version bytes "2.0"

[Luke-Jr]

This should make it compatible with Namecoin addresses...

Here's a revised proposal:
* Bits 128/64 define network class
** 0 = main network
** 64,128 = reserved
** 192 = test network
* Bits 32/16 define network
** 0 = Bitcoin
** 16 = reserved
** 32 = OTHER (next octet)
** 48 = Namecoin

The rest is left up to the network to decide; for Bitcoin, it is:
* Bits 8/4/2 define data class
** 0 = Public key hash
** 2 = reserved
** 4 = Script hash
** 6 = Public key (raw)
** 8 = Signature
** 10 = reserved
** 12 = Private key (raw)
** 14 = OTHER (next octet)
* Bit 1 is freely chosen (for aesthetic assignment)

Re: [Bitcoin-development] Version bytes "2.0"

[Pieter Wuille]

It seems base58 is actually quite terrible for producing nice human-recognizable
addresses, even though base58 is specially intended for human usage. We'll just
have to deal with it, or completely overhaul it and move to a saner encoding.


Luke's proposal is somewhat more drastic than my original one, since it removes
the actual "version" notion from the version bytes, and changes testnet addresses.
However, I think it may be worth it. More data classes have been necessary
before, and new versions haven't. Furthermore, they are far more recognizable to
users, which is something that in particular for OP_EVAL addresses (script hashes)
will be a plus.

Therefore, I'm in favor of the proposal; the new versions would become:

0:   mainnet pubkey hashes ('1', as before)
192: testnet pubnet hashes ('2', instead of 111, 'm' and 'n')
5:   mainnet script hashes ('3'; for OP_EVAL)
196: testnet script hashes ('2', same as normal testnet addresses)
12:  mainnet private keys  ('Q', 'R' or 'S', instead of 128, '5')
204: testnet private keys  ('7', instead of 239, '8' and '9')

Comments?

--
Pieter

Re: [Bitcoin-development] Version bytes "2.0"

[Luke-Jr]

On Monday, December 12, 2011 3:56:01 PM Pieter Wuille wrote:
> It seems base58 is actually quite terrible for producing nice
> human-recognizable addresses, even though base58 is specially intended for
> human usage. We'll just have to deal with it, or completely overhaul it
> and move to a saner encoding.

Or both: use this proposal for 20-byte base58 for now, and overhaul it in the 
future (maybe when the block chain forks?).

> 0:   mainnet pubkey hashes ('1', as before)
> 192: testnet pubnet hashes ('2', instead of 111, 'm' and 'n')
> 5:   mainnet script hashes ('3'; for OP_EVAL)
> 196: testnet script hashes ('2', same as normal testnet addresses)

Looks good here.

> 12:  mainnet private keys  ('Q', 'R' or 'S', instead of 128, '5')
> 204: testnet private keys  ('7', instead of 239, '8' and '9')

These are 32-byte, so have no reason IMO to follow the 20-byte proposal.
Since a lot of services are already using version 128 ('5') for bitcoin 
private keys, and 128 is "reserved" in the 20-byte proposal, I think it's fair 
to leave it alone (for now).

Re: [Bitcoin-development] Version bytes "2.0"

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 423 bytes --]

Why does anyone care what an address looks like?

If the user is seeing an address, that's a usability fail right there. It's
common today because AFAIK nobody finished off the  URL handling support in
the main client for browser integration. It'd be a much better use of time
to finish off that integration and make it easy for people to create links
containing a bitcoin: URL (like with copy/paste of text/html content).

[-- Attachment #2: Type: text/html, Size: 443 bytes --]

Re: [Bitcoin-development] Version bytes "2.0"

[Wladimir]

[-- Attachment #1: Type: text/plain, Size: 1913 bytes --]

All,

I fully agree with Mike Hearn on this. Like email addresses, bank numbers,
phone numbers, IPv4/v6 addresses and such the bitcoin address is just an
opaque identifier for machines to be able to send each other messages.

Base58 was chosen not for human readability but to make it easy to
copy/paste.

Of course, sometimes for security reasons you may want to check the
addresses manually, but it is not the prime usage scenario. Although fun as
a nerd pasttime, I don't think we should encourage "addresses with meaning"
to normal users.

Indeed better to focus on alternative ways that don't involve typing or
even seeing the addresses.

Copy/paste of HTML content is currently not possible. You *can* already
drag&drop the bitcoin: link to the client. Bluematt has a pull request to
automatically handle bitcoin: URLs when clicked in the browser.

Wladimir

On Tue, Dec 13, 2011 at 11:38 AM, Mike Hearn <mike@plan99.net> wrote:

> Why does anyone care what an address looks like?
>
> If the user is seeing an address, that's a usability fail right there.
> It's common today because AFAIK nobody finished off the  URL handling
> support in the main client for browser integration. It'd be a much better
> use of time to finish off that integration and make it easy for people to
> create links containing a bitcoin: URL (like with copy/paste of text/html
> content).
>
> ------------------------------------------------------------------------------
> Systems Optimization Self Assessment
> Improve efficiency and utilization of IT resources. Drive out cost and
> improve service delivery. Take 5 minutes to use this Systems Optimization
> Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 2609 bytes --]

Re: [Bitcoin-development] Version bytes "2.0"

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1419 bytes --]

>
> Base58 was chosen not for human readability but to make it easy to
> copy/paste.
>

It was also chosen for hand-writeability, weirdly enough. That's why it
excludes some confusible characters. But Satoshi didn't really understand
how people would end up using Bitcoin, he originally imagined most
transactions being done directly between pairs of IP addresses.


> Copy/paste of HTML content is currently not possible. You *can* already
> drag&drop the bitcoin: link to the client. Bluematt has a pull request to
> automatically handle bitcoin: URLs when clicked in the browser.
>

That's cool. I hope Matts change gets merged soon. Then the issue becomes
how do people find out about this capability? Expecting people to learn how
to hand-craft Bitcoin links won't work. But all modern operating systems
support copy/paste and drag/drop of rich content. Qt probably makes it easy
to expose an UI like this:

   *Pay me*    [Copy to clipboard]

Clicking the link in the UI would pop up an alert saying something like

   "You can drag this link to an email, chat window or editing program."

Dragging it/pushing the copy button would just set the drag/clipboard data
as a bit of text/html content. So then you can just copy/paste into an
email or HTML editor. It wouldn't work for forums that use bbCode, though I
guess there's no particular reason the forum software can't turn <a href>
into [url=] automatically.

[-- Attachment #2: Type: text/html, Size: 1977 bytes --]

Re: [Bitcoin-development] Version bytes "2.0"

[Wladimir]

[-- Attachment #1: Type: text/plain, Size: 760 bytes --]

>
>
> That's cool. I hope Matts change gets merged soon. Then the issue becomes
> how do people find out about this capability? Expecting people to learn how
> to hand-craft Bitcoin links won't work. But all modern operating systems
> support copy/paste and drag/drop of rich content. Qt probably makes it easy
> to expose an UI like this:
>
>    *Pay me*    [Copy to clipboard]
>
> Clicking the link in the UI would pop up an alert saying something like
>
>    "You can drag this link to an email, chat window or editing program."
>

Good idea! This could be integrated with the QR-code generation (
https://github.com/bitcoin/bitcoin/pull/629) which adds "create a payment
link" functionality (but currently only "exports" this link as a QR code).

Wladimir

[-- Attachment #2: Type: text/html, Size: 1239 bytes --]

Re: [Bitcoin-development] Version bytes "2.0"

[Luke-Jr]

On Tuesday, December 13, 2011 6:07:17 AM Mike Hearn wrote:
> That's cool. I hope Matts change gets merged soon. Then the issue becomes
> how do people find out about this capability? Expecting people to learn how
> to hand-craft Bitcoin links won't work. 

Bitcoin-Qt 0.6 will include a QR Code generator.

> But all modern operating systems support copy/paste and drag/drop of rich
> content. 

No, not really. I've found that dragging and dropping links manages to corrupt 
them most of the time.