Hacker News Reader

Comment by malodyets | Hacker News Reader

I’m a big fan of base58

+ almost as efficient as base64 + no special characters + no padding characters

Unlike Base64 or Base32, Base58 has approximately O(N^2) complexity because it requires iterative division and multiplication operations on big integers. You can't encode a gigabyte of data with Base58 in a reasonable time, but you certainly can with Base64 or Base32.

Seems like a compiler should be able to convert division to shifts and subtractions.

> u8 divmod 58 can be reduced to a u8->u16 multiply, a right shift, and three conditional subtractions; that's not great, but on a modern CPU it's a afterthought compared to the quadratic loop over the input size.

Same topic from 2018: https://news.ycombinator.com/item?id=18409344

I don't understand that comment. How do you handle carry?

I thought base58 runs on 8 byte blocks because 58^11 is slightly larger than 256^8. Then I checked the spec and this is actually not a standard requirement.

Haven't seen that, but how do you work with carry for numbers that are 256^8 < x < 58^11 ?

If we cut off at 8 byte blocks every number would be < 256^8. Encountering x > 256^8 would simplify be invalid.

In that case, there would be padding left in every encoded block. The size overhead would weaken the case for Base58 especially if you consider using it for arbitrarily long data.

Base64 doesn't need padding so that one's easy.

No special characters... I mean it's true, but there's not many places I'm worried about inability to mix in some - and _.

Base58 also avoids a couple confusable characters, but that only matters when copying by hand, and if I'm copying by hand I'd rather use base32.

I'm a big fan of not base anything encoding

Why? Use Vinci for everything?

I like plaintext

Reply on news.ycombinator.com