<p>As far as I can tell &quot;length extension mutation weakness&quot; is the sole problem that needed to be resolved and is resolved by bech32m. But &quot;length extension mutation weakness&quot; includes <a href="https://github.com/sipa/bech32/issues/51" rel="nofollow noreferrer">both</a> insertion and deletion.</p>
<blockquote>
<p>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.</p>
<p>Deletion: if a valid Bech32 string has the suffix qp, removing the q character will produce another valid Bech32 string.</p>
</blockquote>
<p>There are also more complex insertions and deletions that are possible than just &quot;q before final p&quot; too (see Pieter's comment at the bottom) though I haven't found this documented anywhere thus far.</p>
<p>To resolve this problem a <a href="https://github.com/sipa/bips/blob/bip-bech32m/bip-bech32m.mediawiki#bech32m" rel="nofollow noreferrer">new checksum algorithm</a> has been designed by:</p>
<blockquote>
<p>replacing the constant 1 that is xored into the checksum at the end with 0x2bc830a3</p>
</blockquote>
<p>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 <a href="https://bitcoin.stackexchange.com/questions/100508/can-you-break-down-what-data-is-encoded-into-a-bech32-address">defined</a> 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.</p>
<p>Pieter added on <a href="https://github.com/bitcoin/bitcoin/pull/20861#discussion_r552298542" rel="nofollow noreferrer">GitHub</a>:</p>
<blockquote>
<p>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).</p>
</blockquote>
<p>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.</p>
<p>Thanks to Pieter Wuille and Russell O'Connor for some corrections on the original post.</p>

CC BY-SA 4.0
2021-01-05T18:20:49.080Z
The "insertion/deletion of q before final p" is not the only issue that Bech32m addresses, but it does primarily address issues that involve insertions and deletions (generally more complex ones than just "q before final p", though). Both Bech32 and Bech32m have the same performance for substitution-only changes.
Pieter Wuille
CC BY-SA 4.0
2021-01-05T18:21:49.623Z
Yes, you could insert/delete many q before a final p to turn a P2WPKH address into a P2WSH or vice verse. That's a ridiculously unlikely error though.
Pieter Wuille
CC BY-SA 4.0
2021-01-05T18:33:53.727Z
You aren't going to accidentally mistype and add 20 q's, that's for sure! I guess I'm thinking of a different scenario where you think you're sending to the address you normally do but actually you are tricked into sending to the normal address with 20 added q's and the checksum doesn't save you.
Michael Folkson
CC BY-SA 4.0
2021-01-05T18:49:20.380Z
A checksum can't save you from adversarial situations. Their goal is protecting against typos / copy paste errors / transcription errors / errors from being relayed as spoken words / ..., but not against someone intentionally trying to make you send to the wrong thing.
Pieter Wuille
CC BY-SA 4.0
2021-01-05T14:30:09.340Z
2021-01-09T20:22:49.827Z
2021-01-09T20:22:49.827Z
Michael Folkson
<p>What problems identified with <a href="https://bitcoin.stackexchange.com/questions/100508/can-you-break-down-what-data-is-encoded-into-a-bech32-address">bech32</a> addresses have been resolved with the updated <a href="https://github.com/bitcoin/bips/blob/6446f2af0a75e513a0c4bad0ddaad8d798bd5e2d/bip-0350.mediawiki" rel="nofollow noreferrer">bech32m</a>?</p>
<p>I am aware of one problem with the original bech32, namely <a href="https://bitcoin.stackexchange.com/questions/91602/how-does-the-bech32-length-extension-mutation-weakness-work">length extension mutation weakness</a> but I don't know if there were any others.</p>

<bech32-address><taproot><bip350-bech32m>
What problems identified with bech32 addresses have been resolved with the updated bech32m?
Michael Folkson
# What problems identified with bech32 addresses have been resolved with the updated bech32m?

(Asked by: username_0 on 2021-01-05)

What problems identified with [bech32](https://bitcoin.stackexchange.com/questions/100508/can-you-break-down-what-data-is-encoded-into-a-bech32-address) addresses have been resolved with the updated [bech32m](https://github.com/bitcoin/bips/blob/6446f2af0a75e513a0c4bad0ddaad8d798bd5e2d/bip-0350.mediawiki)?

I am aware of one problem with the original bech32, namely [length extension mutation weakness](https://bitcoin.stackexchange.com/questions/91602/how-does-the-bech32-length-extension-mutation-weakness-work) but I don't know if there were any others.

**Tags:** bech32-address, taproot, bip350-bech32m


---

## 1 answers

### Answer by username_0 on 2021-01-05. Score: 3 | Accepted answer

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](https://github.com/sipa/bech32/issues/51) 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 username_1's comment at the bottom) though I haven't found this documented anywhere thus far.

To resolve this problem a [new checksum algorithm](https://github.com/sipa/bips/blob/bip-bech32m/bip-bech32m.mediawiki#bech32m) 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](https://bitcoin.stackexchange.com/questions/100508/can-you-break-down-what-data-is-encoded-into-a-bech32-address) 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.

username_1 added on [GitHub](https://github.com/bitcoin/bitcoin/pull/20861#discussion_r552298542):

> 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 username_1 username_1 and Russell O'Connor for some corrections on the original post.

> **Comments:**
> **username_1**: The "insertion/deletion of q before final p" is not the only issue that Bech32m addresses, but it does primarily address issues that involve insertions and deletions (generally more complex ones than just "q before final p", though). Both Bech32 and Bech32m have the same performance for substitution-only changes.  
> **username_1**: Yes, you could insert/delete many q before a final p to turn a P2WPKH address into a P2WSH or vice verse. That's a ridiculously unlikely error though.  
> **username_0**: You aren't going to accidentally mistype and add 20 q's, that's for sure! I guess I'm thinking of a different scenario where you think you're sending to the address you normally do but actually you are tricked into sending to the normal address with 20 added q's and the checksum doesn't save you.  
> **username_1**: A checksum can't save you from adversarial situations. Their goal is protecting against typos / copy paste errors / transcription errors / errors from being relayed as spoken words / ..., but not against someone intentionally trying to make you send to the wrong thing.  

---

