By an “objective reason”, I meant something along the lines of:  “Truncated 32 bits of double-SHA256 is a bad choice for a checksum, because it has no error correction, relatively poor error detection, terrible performance (time cost)—overall, it’s a choice much inferior to a simple CRC-32.  Its only advantage here is that it’s a hammer you already have in your toolbox; the disadvantage thus is that everything starts to look like a nail.”  A significant technical flaw would certainly warrant some discussion.


True, that’s a particularly awful pair of confusables.  I’ve been thinking on what you said about that.  Fortunately, “1” (one) is not part of the Bech32 base32 alphabet and is never valid in the data part; therefore, I think perhaps there may be a special corner-case for error correction:  When the character “1” (one) is encountered in an invalid Bech32 string, in a position where substituting an “l” (ell) would produce a fully valid Bech32 string including a valid checksum (and only a single such substitution is required), then perhaps automatic error correction (or at least suggestion) should occur notwithstanding the specification’s statement that “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.”

Of course, as you said in your original post, I would not expect users to remember (or even know) the distinction between a “separator” and a “‘data part’ base32 alphabet character”.  My idea here is that maybe implementers should consider autocorrecting this one specific case.  A similar case may apply where no separator at all is encountered, and a single substitution of a “1” (one) for an “l” (ell) would produce a fully valid Bech32 string.

Thoughts from devs/implementers/UX experts?  Should I perhaps mull a concise way to state this in a revision to BIP 173, or would that just be opening a can of worms with (infinitesimal) potential for sending funds to nonexistent addresses?

So as for ells and ones.

Obviously, in this scenario, there are some matters of taste.  I myself am accustomed to base32 identifiers, so it’s easy for me to take to another one.  I suppose that someday, those old-style addresses will be beyond the realm of nostalgia—more like museum-quality antiques; albeit functional ones, for the people with coins in really long-term cold storage.

For my part, I see Bech32 as a positive sign that Bitcoin continues to lead with innovation in a field it created, that of “cryptocurrencies”.  Bech32 already has some uptake amongst altcoins, at least those with a Segwit implementation.

I hope that Bech32 works out for you in your real-world usage, however you find most comfortable to case it.


Hey, I’ll admit to that, too!