Step by step guide to go from public key to a Bech32 encoded address

[pooya87]

i dont understand why they needed to have bech32m if they already have bech32. the more address types that get created i think the worse that is for bitcoin not better. i dont know if anyone else feel that way or not especially though if the address type that is being changed had some type of issue with it that motivated the creation of a related address typing. but i guess they'll keep going. watch out for bech32P anytime soon.

You don't have to worry about anything, in the end you are just copying a string that if nobody had mentioned you wouldn't even know it is a modified encoding scheme! Your wallet does everything behind the scene for you. If it were necessary we would introduce bech32 a to z.

[1714325201]

1714325201

[1714325201]

1714325201

[NotATether]

The more address types that get created i think the worse that is for bitcoin not better.

It only really matters to developers. Normal users who are just sending and receiving bitcoin will not care much about the address as long as it is accepted at the places they need to pay (so could be a problem in the early months of deployment but as time passes it should largely become a non-issue).

[ABCbits]

The actual checksum used in encoding is the result of "polymod" XORed with a constant. This constant is 0x01 for Bech32 (BIP-173) encoding just flipping the least significant bit and is 0x2bc830a3 for Bech32m (BIP-350) encoding. The former is used for witness version 0 addresses and the later for 1+. This is basically the only difference that was introduced in BIP-350.

Thanks for the explanation, it's simpler than i think. Guess i missed it because BIP 173 never use word "constant" when they mention 0x01.

@Coding Enthusiast do you have any plan to create Bech32m version of this guide since the BIP already created and few wallet already implement it?

i dont understand why they needed to have bech32m if they already have bech32. the more address types that get created i think the worse that is for bitcoin not better. i dont know if anyone else feel that way or not especially though if the address type that is being changed had some type of issue with it that motivated the creation of a related address typing. but i guess they'll keep going. watch out for bech32P anytime soon.

Here's why. On a side note, most people won't be able to tell difference between Bech32 and Bech32m. At least unless they know Bech32m is used since witness version 1 which indicated by Bech32 address with prefix bc1p.

Motivation

BIP173 defined a generic checksummed base 32 encoded format called Bech32. It is in use for segregated witness outputs of version 0 (P2WPKH and P2WSH, see BIP141), and other applications.

Bech32 has an unexpected weakness: whenever the final character is a 'p', inserting or deleting any number of 'q' characters immediately preceding it does not invalidate the checksum. This does not affect existing uses of witness version 0 BIP173 addresses due to their restriction to two specific lengths, but may affect future uses and/or other applications using the Bech32 encoding.

This document addresses that by specifying Bech32m, a variant of Bech32 that mitigates this insertion weakness and related issues.

[PrimeNumber7]

i dont understand why they needed to have bech32m if they already have bech32. the more address types that get created i think the worse that is for bitcoin not better. i dont know if anyone else feel that way or not especially though if the address type that is being changed had some type of issue with it that motivated the creation of a related address typing. but i guess they'll keep going. watch out for bech32P anytime soon.

You don't have to worry about anything, in the end you are just copying a string that if nobody had mentioned you wouldn't even know it is a modified encoding scheme! Your wallet does everything behind the scene for you. If it were necessary we would introduce bech32 a to z.

The more address types there are, the greater the chance someone messes something up when trying to create some 3rd party application, or otherwise. If you are a user of this 3rd party application, this will negatively affect you, and if you are a bitcoin user, this has the potential to reflect negatively on bitcoin.

Also, if you are trying to recover your wallet from their seed, having multiple address types adds complexity to the process, and may make some people erroneously believe there is a problem with their seed when they use their seed backup to generate the wrong address type.

[pooya87]

The more address types there are, the greater the chance someone messes something up when trying to create some 3rd party application, or otherwise. If you are a user of this 3rd party application, this will negatively affect you, and if you are a bitcoin user, this has the potential to reflect negatively on bitcoin.

First of all saying "3rd party application" suggests there is a centralized authority that produces bitcoin related applications and anybody else is a third party which doesn't make any sense.
Secondly if a developer is not capable of correct implementation of a simple encoding and by extension address validation, then you have so much more serious things to worry about in all parts of that application than existence of multiple address types and encoding algorithms!

Also, if you are trying to recover your wallet from their seed, having multiple address types adds complexity to the process, and may make some people erroneously believe there is a problem with their seed when they use their seed backup to generate the wrong address type.

That's the inherent property of mnemonics that lack address type indication (and a lot more such as derivation path). Existence of different address types is not a problem here.

[larry_vw_1955]

That's the inherent property of mnemonics that lack address type indication (and a lot more such as derivation path). Existence of different address types is not a problem here.

I don't really see the benefit of new address types that represent the same old public key. they incentived using bech32 but that doesn't mean really that its better. or represents any kind of leap forward in technology. i'm not worried about error checking because i know how to use a clipboard and qrcode reader/scanner.

but for example you can't do bip38 with bech32 as that is not defined in the bip38 standard. so if you do try and do it then you're not going by any bip you're making something up that no one else might know how you did it or have to follow if they tried to implement the same thing.  which is kind of a shame because bip38 was pretty cool. but you definitely can't do that with bech32.

[pooya87]

I don't really see the benefit of new address types that represent the same old public key.

Addresses have never represented public keys, they always represent a script. When a new address is introduced that means a new standard script was introduced (P2PKH > P2SH > P2WPKH/P2WSH > P2TR).

they incentived using bech32 but that doesn't mean really that its better. or represents any kind of leap forward in technology.

It does. Bech32 encoding was introduced to let users use the new SegWit outputs that is was a "leap forward in technology".

but for example you can't do bip38 with bech32 as that is not defined in the bip38 standard. so if you do try and do it then you're not going by any bip you're making something up that no one else might know how you did it or have to follow if they tried to implement the same thing.  which is kind of a shame because bip38 was pretty cool. but you definitely can't do that with bech32.

It depends on what you are doing. If it is for personal encryption then you can easily make a tiny modification in BIP38 and use bech32 address. If it is a wallet that people use, again you can add that option and people will both see the algorithm and can always use it to encrypt/decrypt their keys using that wallet.

[larry_vw_1955]

It does. Bech32 encoding was introduced to let users use the new SegWit outputs that is was a "leap forward in technology".

 a leap forward in error checking maybe but just saying that if you use this address type then we won't make you pay as many fees doesn't mean any great technological achievement. it's kind of arbitrary.

thanks for the comment about bip38 but i'm not willing to accept a modification to it that would use any of the flagbyte that they have reserved for future possible uses.