Pieter Wuille: New Address Type for SegWit Addresses
Why Bitcoin Stack Exchange recommends it
Bitcoin Stack Exchange answerers point people to it for the design reasoning behind bech32 addresses, straight from the person who proposed the format.
Recommended by 3 people across 2 different months, 2018 to 2025.
What it is
A 2017 talk to the SF Bitcoin Developers meetup in which Bitcoin Core developer Pieter Wuille presents his proposal for a new SegWit address format, later standardised as bech32 (BIP 173). He covers the motivation for moving beyond Base58, the base32 character set, and the BCH-based checksum with its strong error detection, including the computer searches used to pick the constants.
What people said
Recommends Tailer · 2018-02 · Bitcoin Stack Exchange · on “Strange output address”
As @pebwindkraft comment, it's the new bitcoin segwit address (bech32), it's supported on bitcoin-core v0.16. Bech32 is a segwit address format specified by BIP 0173. While this address format has been included in some implementations, as of December 2017. If you would know more about it watch this [this video]
Recommends Raghav Sood · 2018-05 · Bitcoin Stack Exchange · on “What the difference between old segwit (3) and new segwit address (bc)?”
The difference lies in the encoding and the underlying representation in the transaction data stored on the blockchain. The 3-segwit addresses are known as P2SH-P2WPKH or P2SH-P2WSH. This stands for Pay-to-witness-pubkey-hash wrapped in pay-to-script-hash and pay-to-witness-script-hash wrapped in pay-to-script-hash respectively. This was done to provide backwards compatibility with existing wallets and allow time to upgrade to the bc1 addresses. The bc1 addresses are known as native segwit addresses. An address starting with bc1 is always going to be segwit, while a 3-address could also be a regular multisig or other script address. Both the 3-address version and the bc1 version require less
Recommends Mike D · 2018-05 · Bitcoin Stack Exchange · on “How is Bech32 based on BCH codes?”
My understanding is that some research went into picking an optimal generator polynomial for the BCH code and then it was hardcoded [LINK] into the bech32 standard. More info in this [this video] talk by Pieter Wuille
Cites bordalix · 2025-03 · Bitcoin Stack Exchange · on “Why doesn't Bech32 use the character "b" in the data part?”
'b' was remove due to similarities with '8'. This comes from RFC 4648 [LINK] You don't need to remove 'l' (lowercase 'L') since '1' (number '1') is already removed Fun note: the order of the character set was thought up in order to maximize one bit errors when people make common errors (like 'z' for '2' or 's' for '5'). Most similar chars are 1 bit apart in the character set table. [LINK] Peter Wuille explains it here [this video]