Creating a new encoding standard based on bech32 for use for cryptographic primitives

[ChristopherA]

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 does), 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 80-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.

Also quoting @sipa in https://github.com/BlockchainCommons/AirgappedSigning/issues/4#issuecomment-620327751:

My comment from BIP173 you're quoting doesn't apply if you don't use error correction (which hopefully no BIP173 implementation provides).

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, as many of the characters allowed in the HRP are not allowed by URLs without escaping.

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 or QR compression optimized encoding?

Some of the items I'd like to see standard URI and QR optimized bech32 encoding of:

• raw entropy (dice, TRNG, etc.)
• master seeds (binary data for saving to BIP39 or SLIP39)
• slip39 shards
• master keys (HD m/O')
• master watch keys
• wallet kesy (derived HD xprv plus path)
• watch keys (derived HD xpub plus path)
• private keys
• public keys
• ECDSA Signatures
• Schnorr Signatures.

-- Christopher Allen