(Some of) the math behind Bech32 addresses

By now, native SegWit, bech32, or BIP-173 addresses have increased significantly in adoption. I’m talking about addresses like bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4. Articles such as the one by bitcoin op-tech have explained excellently how these addresses are used in practice to construct bitcoin transactions. But other than the introduction given by Pieter himself on YouTube, I could find very little layman-accessible explanation for what is actually going on during the encoding. There are some excellent comments in the code itself, but these still require a fair amount of prior knowledge to understand — code isn’t really the place for the full theory to be written out.

There exists a nice step-by-step explanation for how “legacy” addresses are constructed from a public key on the bitcoin wiki. But because Bech32 is designed from some cool (but potentially confusing) mathematics rather than just chucking a hash on the end, this article will hopefully make some of the underlying technical details a bit more transparent for all those interested. A lot of these details are from the BIP, Pieter’s talk, and the code itself, but by bringing them together here, it may help make things a little more accessible. Most of this article will be about how things work, not why exactly they are the way that they are, because its already getting quite long, and I myself am no expect on coding theory.

Apologies in advance for any mistakes or typos. Thanks to Murch and Pieter for helpful feedback. And thanks as always to John Pfeffer for his support of my work. Enjoy :)

Leave a Comment