What problems identified with bech32 addresses have been resolved with the updated bech32m?

Question

What problems identified with bech32 addresses have been resolved with the updated bech32m?

I am aware of one problem with the original bech32, namely length extension mutation weakness but I don't know if there were any others.

Answer 1

As far as I can tell "length extension mutation weakness" is the sole problem that needed to be resolved and is resolved by bech32m. But "length extension mutation weakness" includes both insertion and deletion.

Insertion: if a valid Bech32 string has the suffix p, inserting a single q character immediately before the p will produce another valid Bech32 string.

Deletion: if a valid Bech32 string has the suffix qp, removing the q character will produce another valid Bech32 string.

There are also more complex insertions and deletions that are possible than just "q before final p" too (see Pieter's comment at the bottom) though I haven't found this documented anywhere thus far.

To resolve this problem a new checksum algorithm has been designed by:

replacing the constant 1 that is xored into the checksum at the end with 0x2bc830a3

Bech32m encoding will only be used for SegWit output versions 1 and above. Version 0 will continue to use bech32 as the length extension mutation weakness does not present a problem for version 0 as SegWit v0 addresses are restricted to two specific lengths (No such length restrictions are currently imposed on higher SegWit version addresses.) They are defined to only be 42 characters (P2WPKH) or 62 characters (P2WSH). Although technically you could insert 20 q characters to make a P2WSH address with a valid checksum from a P2WPKH address, the checksum is not designed to guard against adversarial situations or insertions this large. The goal of the checksum is to protect against typos, copy paste errors, transcription errors, errors from being relayed as spoken words.

Pieter added on GitHub:

I think it's a bad idea to have multiple addresses valid for the same scriptPubKey. It only results in confusion when decoding/recoding doesn't roundtrip. v0 outputs use bech32, and I don't think this should ever change, for better or for worse. It also worsens error detection to 29 bits (as every v0 output now has two valid checksums).

Once you have proposed two different encoding schemes (bech32 and now bech32m) this presents a challenge to wallets of knowing which encoding is used and the bech32m draft BIP hence decides to make the two entirely incompatible ie it is impossible for a bech32m address to be a valid bech32 address and vice versa.

Thanks to Pieter Wuille and Russell O'Connor for some corrections on the original post.