bech32m

mikedilger commented

2025-03-23 06:52:31 +13:00

(Migrated from github.com)

bech32 has an insertion/deletion weakness: https://github.com/sipa/bech32/issues/51

If starting over, use bech32m.

bech32 has an insertion/deletion weakness: https://github.com/sipa/bech32/issues/51 If starting over, use bech32m.

melvincarvalho commented

2025-04-04 01:34:09 +13:00

(Migrated from github.com)

100% bech32m but why even have a suffix at all? Seems like a big mistake.

Just use

npub

tb

Or something like this.

Npub is also a big problem because it doesnt pass the "test of independent invention". If another system were to come up with an npub encoduing, no sane system would use segwit suffix on a taproot address and prefix, which is just a bug.

A solution is to allow the libraries to shift gradually, whatever the new solution.

Make the suffix optional would be a good first step.

100% bech32m but why even have a suffix at all? Seems like a big mistake. Just use npub<taproot address> tb<taproot address> Or something like this. Npub is also a big problem because it doesnt pass the "test of independent invention". If another system were to come up with an npub encoduing, no sane system would use segwit suffix on a taproot address and prefix, which is just a bug. A solution is to allow the libraries to shift gradually, whatever the new solution. Make the suffix optional would be a good first step.

mikedilger commented

2025-04-04 10:55:19 +13:00

(Migrated from github.com)

Yeah I only care for the character set of bech32, not the rest of it.

👍 1

melvincarvalho commented

2025-07-14 22:18:33 +12:00

(Migrated from github.com)

An important omission is the version number which provides future proofing.

I suggest current n- encodings either be treated as version=null or version=0

All next versions start from a new version number

If there is a taproot prefix, you need a taproot checksum
checksum should only be required when it is needed (its not in a lot of cases)
current npubs should be for display purposes only -- all protocols should operate on 64/65 char hex

An important omission is the version number which provides future proofing. I suggest current n- encodings either be treated as version=null or version=0 All next versions start from a new version number - If there is a taproot prefix, you need a taproot checksum - checksum should only be required when it is needed (its not in a lot of cases) - current npubs should be for display purposes only -- all protocols should operate on 64/65 char hex

mikedilger commented

2025-07-15 10:40:04 +12:00

(Migrated from github.com)

Ok. I also like zbase32 except that it doesn't have error correction or error detection. I don't like the fact that bech32 is specified as part of bitcoin and tied into things like segwit and taproot, neither of which are relevant to a binary encoding scheme.

Maybe the time has come to take base32, zbase32, and bech32 as inputs, and make a new one that ticks all the boxes, including a version number.

Ok. I also like zbase32 except that it doesn't have error correction or error detection. I don't like the fact that bech32 is specified as part of bitcoin and tied into things like segwit and taproot, neither of which are relevant to a binary encoding scheme. Maybe the time has come to take base32, zbase32, and bech32 as inputs, and make a new one that ticks all the boxes, including a version number.

mikedilger commented

2025-07-15 15:45:28 +12:00

(Migrated from github.com)

I just whipped this up https://github.com/mikedilger/hum32 but I forgot the version number! lol

Rows
Columns

bech32m #53