<p>There are multiple aspects to the design of bech32. There is the choice of character set (i.e. which characters are included in the 32 options and which characters are excluded because they visually look like other characters e.g. 1 because it looks like l), the mapping of specific bits to this character set, the type of checksum to use and the final address structure.</p>
<p><a href="https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#cite_note-4" rel="noreferrer">BIP 173</a> explains the choice of character set.</p>
<blockquote>
<p>The character set is chosen to minimize ambiguity according to <a href="https://hissa.nist.gov/%7Eblack/GTLD/" rel="noreferrer">this</a> visual similarity data, and the ordering is chosen to minimize the number of pairs of similar characters (according to the same data) that differ in more than 1 bit. As the checksum is chosen to maximize detection capabilities for low numbers of bit errors, this choice improves its performance under some error models.</p>
</blockquote>
<p>The mapping of bits to bech32 characters is also included in the <a href="https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#bech32" rel="noreferrer">BIP</a>.</p>
<p>e.g. 11 maps to t (3 on x axis and +8 on y axis) and 30 maps to 7 (6 on x axis and +24 on y axis)</p>
<p><a href="https://i.sstatic.net/NSCUe.png" rel="noreferrer"><img src="https://i.sstatic.net/NSCUe.png" alt="bech32 mapping" /></a></p>
<p>Note that although 1 is included in bech32 addresses as a separator (see <a href="https://bitcoin.stackexchange.com/questions/100508/can-you-break-down-what-data-is-encoded-into-a-bech32-address">here</a>) the character 1 is not included in the permitted character set of bech32. Nothing maps to 1 in this mapping.</p>
<p>Pieter Wuille <a href="https://diyhpl.us/wiki/transcripts/sf-bitcoin-meetup/2017-03-29-new-address-type-for-segwit-addresses/" rel="noreferrer">explained</a> the rationale for this bit to character mapping at SF Bitcoin Devs in March 2017:</p>
<blockquote>
<p>The reason for this is we were able to select our code to optimize for low bit error rates. Wouldn’t it be great if we could choose the character set in such a way that 1 bit errors are more likely than non 1 bit errors. This character set is the result of another year of CPU time to optimize for this. We found a bunch of information on tables for similarity between various characters. What you can see on this slide, the z and the 2 are considered similar in some fonts or writing. As you can see they are 8 apart. One is 2 and the other is 10 so they are 1 bit apart. And r and t are 1 bit apart. And y and v are 1 bit apart. And x and k are 1 bit apart. And e and a are 1 bit apart. And s and 5 are 1 bit apart. And 4 and h are 1 bit apart. There are way more similar errors overlaid in this data that you can look for. It’s pretty cool. We made a character set that optimizes for 1 bit errors. As a result our code is distance 6 for 1 bit errors. If you just look at these 1 bit errors we guarantee 5 errors. If you only make errors like this you can detect 5.</p>
</blockquote>

CC BY-SA 4.0
2020-12-11T16:01:01.923Z
2020-12-11T16:41:58.127Z
2020-12-11T16:41:58.127Z
Michael Folkson
<p>There are multiple existing <a href="https://en.wikipedia.org/wiki/Base32" rel="noreferrer">base32</a> encodings (<a href="http://www.faqs.org/rfcs/rfc3548.html" rel="noreferrer">RFC 3548</a>/4648, <a href="https://philzimmermann.com/docs/human-oriented-base-32-encoding.txt" rel="noreferrer">z-base-32</a>, Crockford's etc). Why did bech32 define a new one rather than use an existing one?</p>

<segregated-witness><bech32-address><address-format>
Why did bech32 define a new base32 encoding scheme rather than use an existing one?
Michael Folkson
# Why did bech32 define a new base32 encoding scheme rather than use an existing one?

(Asked by: username_0 on 2020-12-11)

There are multiple existing [base32](https://en.wikipedia.org/wiki/Base32) encodings ([RFC 3548](http://www.faqs.org/rfcs/rfc3548.html)/4648, [z-base-32](https://philzimmermann.com/docs/human-oriented-base-32-encoding.txt), Crockford's etc). Why did bech32 define a new one rather than use an existing one?

**Tags:** segregated-witness, bech32-address, address-format


---

## 1 answers

### Answer by username_0 on 2020-12-11. Score: 5 | Accepted answer

There are multiple aspects to the design of bech32. There is the choice of character set (i.e. which characters are included in the 32 options and which characters are excluded because they visually look like other characters e.g. 1 because it looks like l), the mapping of specific bits to this character set, the type of checksum to use and the final address structure.

[BIP 173](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#cite_note-4) explains the choice of character set.

> The character set is chosen to minimize ambiguity according to [this](https://hissa.nist.gov/%7Eblack/GTLD/) visual similarity data, and the ordering is chosen to minimize the number of pairs of similar characters (according to the same data) that differ in more than 1 bit. As the checksum is chosen to maximize detection capabilities for low numbers of bit errors, this choice improves its performance under some error models.

The mapping of bits to bech32 characters is also included in the [BIP](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#bech32).

e.g. 11 maps to t (3 on x axis and +8 on y axis) and 30 maps to 7 (6 on x axis and +24 on y axis)

[![bech32 mapping](https://i.sstatic.net/NSCUe.png)](https://i.sstatic.net/NSCUe.png)

Note that although 1 is included in bech32 addresses as a separator (see [here](https://bitcoin.stackexchange.com/questions/100508/can-you-break-down-what-data-is-encoded-into-a-bech32-address)) the character 1 is not included in the permitted character set of bech32. Nothing maps to 1 in this mapping.

Pieter Wuille [explained](https://diyhpl.us/wiki/transcripts/sf-bitcoin-meetup/2017-03-29-new-address-type-for-segwit-addresses/) the rationale for this bit to character mapping at SF Bitcoin Devs in March 2017:

> The reason for this is we were able to select our code to optimize for low bit error rates. Wouldn’t it be great if we could choose the character set in such a way that 1 bit errors are more likely than non 1 bit errors. This character set is the result of another year of CPU time to optimize for this. We found a bunch of information on tables for similarity between various characters. What you can see on this slide, the z and the 2 are considered similar in some fonts or writing. As you can see they are 8 apart. One is 2 and the other is 10 so they are 1 bit apart. And r and t are 1 bit apart. And y and v are 1 bit apart. And x and k are 1 bit apart. And e and a are 1 bit apart. And s and 5 are 1 bit apart. And 4 and h are 1 bit apart. There are way more similar errors overlaid in this data that you can look for. It’s pretty cool. We made a character set that optimizes for 1 bit errors. As a result our code is distance 6 for 1 bit errors. If you just look at these 1 bit errors we guarantee 5 errors. If you only make errors like this you can detect 5.


---

