Hacker News Reader

Comment by wp381640 | Hacker News Reader

That’s draft 1 from 2019, draft 2 from a couple months ago which adds more and fixes the test vectors is here:

https://tools.ietf.org/html/draft-msporny-base58-02

Also of note is that Bitcoin has since moved onto bech32 - the shortcomings of base56 are discussed in the first section:

https://en.bitcoin.it/wiki/BIP_0173

Pieter Wuille’s talk on the design and motivations is great:

https://youtu.be/NqiN9VFE4CU

View on HN

It's worth pointing out that several of the concerns mentioned here are specific to the Bitcoin protocol (e.g. SHA256^2 hashing) and aren't relevant to the use of Base58 as a general encoding scheme. The main issues that are non-Bitcoin-specific are: compatibility with QR encoding schemes, difficulty reading out loud mixed case strings, and higher efficiency encoding to Base32 (you can do it all with CPU-friendly bitwise operators).

So if you care about either of those things, then a Base32 encoding may well be good for you. But personally, my use of encodings like these tends to be for GUIDs and such, which I want to encode as a string, take up as little space as possible in URLs, and be maximally compatible with URL parameters and such. Base58 works great for that, and indeed I've been using it for that purpose for almost a decade now. There are some pretty serious efficiency losses from stepping down to Base32 that I don't want to incur (you're almost halving the size of your alphabet, so every byte you want to encode requires nearly another entire bit).

And, crucially, I'm not actually ever even decoding/encoding these strings back to their numeric value because the string itself then becomes the unique identifier (as it's way easier to work with in the fullstack from DB all the way on up through front-end than a byte or GUID type would be), so the encoding efficiency improvements that are salient for Bitcoin when you have thousands of these to decode in each block you want to validate just don't matter.

The critical argument for base32 over base58 in my mind is being able to write the ids as filenames/folder names on macOS without conflicts (APFS is case-insensitive by default).

Wow, how strange. I didn't realize MacOS did that. I don't actually use MacOS for anything development-related though (yay Linux), so it doesn't affect me. We're also not using these IDs in filenames, though I could see how one might want to do so.

Yes, macOS is case-insensitive and case-preserving.

The option to use the case-sensitive version of HFS+ and now APFS never really caught on.

...but why are you using base58--which notably focuses on a feature specifically for the thing you are saying you don't care about: ensuring that characters don't look like each other--instead of the nearly-universally-implemented (and much more efficient to execute) "url-safe base64" (which drops the = sign padding and replaces + and / with - and _).

I don't want any non-alphanumeric characters in my identifiers. It visually breaks up identifiers in misleading ways and doesn't always play nice with double-clicking. So I could have gone with a Base62 implementation over a Base58 one, but the latter is more common, and even still, it can be useful to reduce visual confusion because people (at least developers) will be looking at these identifiers, even if they're not typing them in.

The test vectors still don't make sense in the updated version. The inputs should be byte sequences, not text.

Read the authors:

S. Nakamoto, BitCoin

Huh?

I wonder if there is any verification

He is assumed to have mined many coins back in the beginning and he can verify himself by spending them.

They are unlikely to do so since those coins are massively looked upon and they're very careful about not disclosing their identity.

It's not necessary to spend to verify, the Bitcoin protocol allows a signed message to demonstrate ownership of the private key for an address.

https://www.monperrus.net/martin/perfect-ocr-digital-data

https://github.com/bitcoin/bips/blob/master/bip-0039.mediawi...

Satoshi Nakamoto came up with the Base58 encoding in the original Bitcoin whitepaper. It's fair to credit him in some manner even if he didn't have any direct involvement in this most recent standards doc.

I would doubt that he wrote this article. There was no public appearance of him in the last ten years.

"It's fair to credit him in some manner even if he didn't have any direct involvement in this most recent standards doc."

> Satoshi Nakamoto came up with the Base58 encoding in the original Bitcoin whitepaper

There is no mention of Base58 in the whitepaper. http://bitcoin.org/bitcoin.pdf

Sorry, it was in the code repo when he released Bitcoin.

Reply on news.ycombinator.com