Version bytes "2.0"

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

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

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)

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?

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).

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).

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
>
>

>
> 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.

>
>
> 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

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.