Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Base58

en.wikipedia.org

Post reply on HN
Print view View original

11–20 of 44 posts

Re: Base58

#11

Post by athenot »

decentralised wrote: post #4

Why base-58 instead of standard base-64 encoding? - Don't want 0OIl characters that look the same in some fonts and could be used to create visually identical looking data. - A string with non-alphanumeric characters is not as easily accepted as input. - E-mail usually won't line-break if there's no punctuation to break at. - Double-clicking selects the whole string as one word if it's all alphanumeric. https://githu…

This is a similar encoding as airline reservation numbers, except it also has lowercase characters. But the requirements are very similar. It's amazing how much confusion is removed by suppressing ambiguities between number 0 vs. letter O and number 1 vs. letter I.

For reservation numbers, doing away with case makes it easier to speak the number over the phone.

Re: Base58

#12

Post by diggan »

If you can't get enough of Base-encodings, there is a project called "multibase" (https://github.com/multiformats/multibase) that lets you encode which Base-encoding you are using, together with the data itself, so it's easier to know what data you are received/sending.

The basic format is `` and the "varint-base-encoding-code" comes from https://github.com/multiformats/multibase/blob/master/multib...

Re: Base58

#15

Post by eesmith »

lifthrasiir wrote: post #7
adzm wrote: post #2

I love interesting representations of binary data, base 58 included, but this article is so scant on details. I'm sure someone could even add a brief overview of the algorithm and samples and it's limitations and idiosyncrasies, such as how it handles things like padding etc.

I think the article is good as is, because base58 is actually pretty dissimilar to most binary-to-text encodings. Surprisingly many encodings are just base 2^k (16, 32, 64 and 128 [1]), some have converged to base 85 (because 85^5 / 2^32 ~= 1.03, i.e. just enough to represent 4 octets in 5 units). This is because binary-to-text encodings are not expected to use costly bigint operations for an arbitrary-length payload…

"Base36 and base58 are the only common exceptions"

Isn't Ascii85/Base85 at least as common as those? Quoting the Wikipedia entry for it, "Its main modern uses are in Adobe's PostScript and Portable Document Format file formats, as well as in the patch encoding for binary files used by Git"

Python includes it as part of the standard library. Using the example from the WP entry:

  >>> s = r"""Cj@.4Gp$d7F!,L7@@3BB/F*&OCAfu2/AKY
  ... i(DIb:@FD,*)+C]U=@3BN#EcYf8ATD3s@q?d$AftVqCh[NqF-FD5W8ARlolDIa
  ... l(DIduD.RTpAKYo'+CT/5+Cei#DII?(E,9)oF*2M7/c~>"""
  >>> import base64
  >>> base64.a85decode(s, adobe=True)
  b'Man is distinguished, not only by his reason, but by this singular
  passion from other animals, which is a lust of the mind, that by a
  perseverance of delight in the continued and indefatigable
  generation of knowledge, exceeds the short vehemence of any carnal
  pleasure.'

Re: Base58

#16

Post by strainer »

decentralised wrote: post #4

Why base-58 instead of standard base-64 encoding? - Don't want 0OIl characters that look the same in some fonts and could be used to create visually identical looking data. - A string with non-alphanumeric characters is not as easily accepted as input. - E-mail usually won't line-break if there's no punctuation to break at. - Double-clicking selects the whole string as one word if it's all alphanumeric. https://githu…

Knocking out similar characters is a good idea but could be done to base32 to make it a little handier. I don't feel adding case sensitivity is worth a 15% reduction in string length.

Re: Base58

#17

Post by ur-whale »

Base58 isn't a great choice from an implementation point of view.

It basically requires a bignum library (or a specialized version that can do divisions of arbitrary long numbers by 58), and conversion is slow as hell.

Either you end up pulling in a full bignum library, or you have to use error-prone, clunky specialized code you don't have time to try and understand and verify.

Of all the design choices Satoshi made, this is far from the best one.

Re: Base58

#19

Post by gpvos »

_eht wrote: post #13

I'm more of a fan of BasE91 and I believe more people should be using it.

Why? It's only a minuscule improvement over ASCII85, which is a well-established encoding. I couldn't find a rationale for it anywhere.

Re: Base58

#20

Post by eesmith »

ur-whale wrote: post #17

Base58 isn't a great choice from an implementation point of view. It basically requires a bignum library (or a specialized version that can do divisions of arbitrary long numbers by 58), and conversion is slow as hell. Either you end up pulling in a full bignum library, or you have to use error-prone, clunky specialized code you don't have time to try and understand and verify. Of all the design choices Satoshi made,…

The implementations at https://github.com/search?q=Base58 don't look like they use a bignum package, nor do that look particularly slow or complicated. The main encoding loop for https://github.com/luke-jr/libbase58/blob/master/base58.c is:

    for (i = zcount, high = size - 1; i  high) || carry; --j)
		{
			carry += 256 * buf[j];
			buf[j] = carry % 58;
			carry /= 58;
		}
         }
Post reply on HN