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 #4 (comment):

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

[stepansnigirev]

• wallet kesy (derived HD xprv plus path)
• watch keys (derived HD xpub plus path)

Maybe you want to look into this:
https://github.com/satoshilabs/slips/blob/master/slip-0032.md

It doesn't include derivation path and parent fingerprint, but can be used as a starting point. It is already using bech32 encoding but is not widely adapted. Actually I've never seen these bech32-xpubs in the wild.

[ChristopherA]

@wolfmcnally has written up a research report on using a derivative of bech32 that we are calling bc32 at https://github.com/blockchaincommons/research and has been implemented in our bech32 library (which supports both) https://github.com/blockchaincommons/bc-bech32

One specific goal Blockchain Commons has in the short term is a cross-wallet QR standard for encoding master seeds (the binary root of both BIP39 and SLIP39), and for encoding SLIP39 shards, and we'd like to see bc32 encoding for this, and possibly some form of URL compatible prefix.

-- Christopher Allen