6 ms·

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

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 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 https://en.bitcoin.it/wiki/BIP_0173 Pieter Wuille’s talk on the design and motivations is great: https://youtu.be/NqiN9VFE4CU https://youtu.be/NqiN9VFE4CU

kevmoo1 6y ago
Read the authors: S. Nakamoto, BitCoin Huh?
- abricot 6y ago
  I wonder if there is any verification
  - rini17 6y ago
    He is assumed to have mined many coins back in the beginning and he can verify himself by spending them.
    - znpy 6y ago
      They are unlikely to do so since those coins are massively looked upon and they're very careful about not disclosing their identity.
    - lozf 6y ago
      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.
- deleted 6y ago
  [deleted]
- CydeWeys 6y ago
  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.
  - hda111 6y ago
    I would doubt that he wrote this article. There was no public appearance of him in the last ten years.
    - CydeWeys 6y ago
      "It's fair to credit him in some manner even if he didn't have any direct involvement in this most recent standards doc."
  - wcoenen 6y ago
    > 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 http://bitcoin.org/bitcoin.pdf
    - CydeWeys 6y ago
      Sorry, it was in the code repo when he released Bitcoin.
- based2 6y ago
  https://www.monperrus.net/martin/perfect-ocr-digital-data https://www.monperrus.net/martin/perfect-ocr-digital-data https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki https://github.com/bitcoin/bips/blob/master/bip-0039.mediawi...
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 ago
  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).
  - CydeWeys 6y ago
    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.
    - alwillis 6y ago
      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.
wcoenen 6y ago
The test vectors still don't make sense in the updated version. The inputs should be byte sequences, not text.

kevmoo1 6y ago

Read the authors: S. Nakamoto, BitCoin Huh?

abricot 6y ago
I wonder if there is any verification
- rini17 6y ago
  He is assumed to have mined many coins back in the beginning and he can verify himself by spending them.
  - znpy 6y ago
    They are unlikely to do so since those coins are massively looked upon and they're very careful about not disclosing their identity.
  - lozf 6y ago
    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.
deleted 6y ago
[deleted]
CydeWeys 6y ago
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.
- hda111 6y ago
  I would doubt that he wrote this article. There was no public appearance of him in the last ten years.
  - CydeWeys 6y ago
    "It's fair to credit him in some manner even if he didn't have any direct involvement in this most recent standards doc."
- wcoenen 6y ago
  > 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 http://bitcoin.org/bitcoin.pdf
  - CydeWeys 6y ago
    Sorry, it was in the code repo when he released Bitcoin.
based2 6y ago
https://www.monperrus.net/martin/perfect-ocr-digital-data https://www.monperrus.net/martin/perfect-ocr-digital-data https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki https://github.com/bitcoin/bips/blob/master/bip-0039.mediawi...

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 ago
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).
- CydeWeys 6y ago
  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.
  - alwillis 6y ago
    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.

wcoenen 6y ago

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