4 ms·
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
by CydeWeys 6y ago
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.
- nikisweeting 6y agoThe 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).
- CydeWeys 6y agoWow, 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.
- alwillis 6y agoYes, macOS is case-insensitive and case-preserving. The option to use the case-sensitive version of HFS+ and now APFS never really caught on.
- saurik 6y ago...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 _).
- CydeWeys 6y agoI 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.