Consider encoding: Bech32

[dhh1128]

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

[will-richards-ii]

I think BCH would be a great error correction to add to multiformats, but not under the bases. Bose–Chaudhuri–Hocquenghem codes or other polynomial error correction or polynomial shares schemes would be great. Perhaps this should be a multicodec instead.

[grondilu]

Bech32 by itself is not a binary-to-text encoding, as it doesn't contain any padding convention. It can only be used to encode multiples of 5 bits.

[danpape]

We'd like to resurrect this issue. While the Bech32 spec (BIP 0173) does specify that valid input data come from a small range of values (0-31), many implementations offer some sort of "convert bits" function that can convert back and forth between the 0-31 range and a full 0-255 range. We've created a few bech32 implementations (c++, java, rust), and would like add two new entries to the multibase table, perhaps something like:

U+0065,   e,     bech32,     BIP173,                   draft
U+0045,   E,     bech32pad,  BIP173 - with padding,    draft

If that is acceptable, what else would we need to provide? Do we need to offer a full multibase implementation, or could we submit patches to existing implementations that would allow them to encode and decode bech32?

[grondilu]

many implementations offer some sort of "convert bits" function

Precisely : this is implementation-dependent. It's not specified.

I myself implemented bech32 once, and at first I thought I could do it as binary-to-text encoding, only to realize I could not do it without adding arbitrary conventions. As such I don't think it is appropriate for multibase, unless the bitcoin community updates BIP 0173 to make it a true binary-to-text format.

[rvagg]

@danpape does your implementation follow conventions set elsewhere or are you constructing your own conventions to make it workable?

I'd say that we could add new formats here, but you'd have to be careful with naming—a plain "bech32" might be misleading if there's not a generally agreed convention to make it work for the full range of inputs or it was appropriately strict in what it could do. But as you can see from other entries, there is space for custom formats, the stand-out example being "base58flickr" and "base58btc" being two ways to achieve a base58, but they're appropriately named. There's also an https://github.com/multiformats/multibase/tree/master/rfcs directory that can house additional documentation needed to support an entry where it's not obvious from an external resource, like an IETF RFC.

I think though it might be difficult to get something over the line if you're just showing up with your own idea that's not supported by an existing ecosystem or community; some measure of user-weight to help justify an entry. We're a little more limited in this table than in the multicodec table in the number of good lead characters we can use unless you're happy with a multibyte unicode prefix I guess, which we have a lot of! base256emoji is easier to squish in because it's got an appropriately ridiculous prefix that's not really taking up space.