12 Jan
2014
12 Jan
'14
5:51 a.m.
On Jan 11, 2014, at 5:47 AM, Adam Back <adam@cypherspace.org> wrote:
> Bitcoin base58 seemed a to have some minor unfortunate side effects to me,
> the intent is good to avoid transcription error, but surely one could find
> 64-chars. it could have easily been base 60 to start with (dont delete both
> 0 and O, and 1 and l just make the equivalent!).
Possible, but breaks string compare. Also adds human confusion in interpretation/typing.
> Then you have URL encoding
> ambiguity,
oh … yes. same point
> C/python/bash programming string quoting that rules out some more
> non alphanum chars. (base 64 includes +/). Just seems some ugly code mess
> and implications for vanity address etc to deal with non-power-of-2
> encoding.
Yes … code is very ugly, Human usability is more important ...
>
> Adam
>
> On Sat, Jan 11, 2014 at 10:58:48AM +0100, stef wrote:
>>> > 1l0$WoM5C8z=yeZG7?$]f^Uu8.g>4rf#t^6mfW9(rr910
>>> one of several possible text encodings
>>> Others might include:
>>> - base 29
>>> - base 59
oops intended base 58
>>> - base 4096 (for UTF8 channels)
base64: "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/“
compact, nice power of 2, human transcription errors likely
base58: “123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz”
fairly readable, relatively compact
base29: “ABCDEFGHJKMNPQRTUVWXYZ2346789"
base 29 assumes lower upper case equivalence, always converts to upper for decode
(removes 5,S 0,O i,1,i,I )
base 29 has the best human usability/readability and is not mangled
very good for license keys and short sequences
… 1/2 of efficiency (losing lower versus upper)
>> i like base85. ;)
oh - thanks, assume you mean RFC1924
base85: “0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz!#$%&()*+-;<=>?@^_`{|}~”
nice shorter encoding. Not URL or human friendly, works well for email cut/paste ‘<‘ might be problematic for web usage.
Paul
>>
>> diversity!