Re: The (not so) great base-encoding debate of 2020 (was: Re: Question on use of base64 vs base64url in modern specifications)

>
> 3. Size efficiency.
>

Regarding size efficiency, It's probably worth considering the space saving
of encodings like base64url only when thinking about large data stores of
public keys and make that a separate concern imo.  I'm not sure that size
efficiency matters for an individual key (again imo).

whereas, base64url will be copyable sometimes, and
> other times, a double click will result in a bad copy/paste (because of
> a breaking character in the base64url value).
>

If the data is _not_ something like a public key and arbitrary length,
base64url has definite space saving advantages, however it would be nice if
there was a middle ground that didn't have the control character that
breaks copy-paste-ability (guessing that's what the issue is).

As for the benefits of bech32, I honestly don't see it... yes, there is
> error correction, but once you get to 32 bytes, you've added close to
> 40% overhead... doesn't seem worth it to me unless you know a human
> being is going to be reading the value and something bad is going to
> happen if they get it wrong (payment going to wrong address, for example).
>

Per https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki

   - Base58 needs a lot of space in QR codes, as it cannot use the
*alphanumeric
   mode*.
   - The mixed case in base58 makes it inconvenient to reliably write down,
   type on mobile keyboards, or read out loud.
   - The double SHA256 checksum is slow and has no error-detection
   guarantees.
   - Most of the research on error-detecting codes only applies to
   character-set sizes that are a prime power
   <https://en.wikipedia.org/wiki/Prime_power>, which 58 is not.
   - Base58 decoding is complicated and relatively slow.

If you add 5. computation efficiency bech32 may have some advantage over
base58 because of the double SHA256 used in base58.

Cheers,
-Yancy

On Mon, Apr 27, 2020 at 11:50 PM Christopher Allen <
ChristopherA@lifewithalacrity.com> wrote:

>
> On Mon, Apr 27, 2020 at 9:27 PM Manu Sporny <msporny@digitalbazaar.com>
> wrote:
>
>> As for the benefits of bech32, I honestly don't see it... yes, there is
>> error correction, but once you get to 32 bytes, you've added close to
>> 40% overhead... doesn't seem worth it to me unless you know a human
>> being is going to be reading the value and something bad is going to
>> happen if they get it wrong (payment going to wrong address, for example).
>>
>
> Bech32/64/128 is NOT suitable as a general encoding format. It is,
> however, very useful for confirming a public key or signature over the
> phone, offering a public key to someone else to add into a multisignature,
> recovery of a Shamir secret sharing shard from a friend using the human
> ability to identify voices, or for use in other low bandwidth places
> scenarios (radio, satellite, etc.).
>
> I really believe that it is not the right solution for more than 128
> bytes, especially in situations where error correction is not needed, and
> error correction can be done more efficiently in other ways.
>
>  See issue https://github.com/BlockchainCommons/AirgappedSigning/issues/5 for
> more details.
>
> — Christopher Allen
>