Creating an encoding standard based on bech32

Blockchain Commons has been exploring the use of bech32 for encoding small
data for use in URIs and QR codes, in particular for keys, shards,
signatures, etc.

Bech32 is specified in
https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki and has been
updated in something we've been calling bech32bis at
https://gist.github.com/sipa/a9845b37c1b298a7301c33a04090b2eb to address a
specific bug.

The advantage of bech32 is not only that it eliminates commonly visual
characters "1", "b", "i", and "o" (like base58), but that it does not only
error-detection, but also error correction. This means that you can know
where in the string the characters are incorrect.

This feature could be particularly useful with public keys and signatures,
as it allows for someone to use voice, QR or other low-bandwidth unreliable
(but hopefully less-censorable) channels to confirm these cryptographic
primitives.

A limitation we have to be careful about is that this capability only works
for some sizes of data, and is optimized for 40 bytes, and is great for
common sizes of cryptographic data of 32 to 64 bytes, but looses or even
make problematic for byte sizes much larger (I've been in conversations
with Peter Wuille about another one that is optimized for around 128 bytes)

Quoting @sipa in BIP-0173:

> An unfortunate side effect of error correction is that it erodes error
detection: correction changes invalid inputs into valid inputs, but if more
than a few errors were made then the valid input may not be the correct
input.…Because of this, implementations SHOULD NOT implement correction
beyond potentially suggesting to the user where in the string an error
might be found, without suggesting the correction to make.


Another problem is that the bech32 specification offers more than just the
encoding format and includes some items like the human-readable part (HRP)
and "1" as the separator between, which can cause a problem with its use in
URI schemes.

Is there any interest in formalizing a new encoding standard for small (32,
64 or 128 byte) cryptographic standards? Or should we stick with bas64url
or work on base58?

— Christopher Allen