sipa/bech32

Code snippets and analysis of the Bech32 format

bech32's Issues

JS Version encoder doesn't work as the python one

The string: https://x.xyz/?key=abc gives:

Python gives:

lnurl1dp68gurn8ghj77pw0puh5telddjhj0tpvf3s8vj45m

JS gives:

lnurl1qqqqqqqqqqqqqqqqqqqqqqpfqpfqpxqzfqzpqq

Could someone explain this?

bech32 decoder looks for the first '1' as the HRP separator, not the last '1' as specified

bech32/ref/c/segwit_addr.c

Lines 95 to 99 in 60848c2

	*data_len = 0;
	while (*data_len < input_len && input[(input_len - 1) - *data_len] != '1') {
	++(*data_len);
	}
	hrp_len = input_len - (1 + *data_len);

https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#bech32 says that the last '1' in the string is the HRP separator. The reference code is inconsistent with that and with Bitcoin Core.

How generate bech with wrong ecoding ?

How generate bech with wrong encoding i need this for tests.

extra things to test

Sweep through each valid input and make every 1 bit error, every adjacent character transposition error.

Add some invalid cases that contain unicode bytes that if to-uppered or to-lowered would result in a valid address (including where just the length changes).

Inputs where ignoring the most significant bit would result in a valid address.

Uncovered parts on pull #21

P2PKH to bech32

Sry if this is a dumb questions. But as title says.

I have for example 1LKp8CTu2b4VDvybY9iMn3DoV1cm6ZLsrR address created from bitcoinjs-lib/coinjs-lib/bip39 and i want to convert it to bech32?

How can i do it? Thanks for the responses in advance <3

Haskell implementation of `bech32Encode` generates invalid output if the HRP contains upper case characters.

Overview

When bech32Encode is called with a human-readable part that contains one or more upper-case characters, it produces in an invalid Bech32 string that cannot be decoded with the bech32Decode function.

Analysis

As part of the encoding process, the human-readable part is converted to lower case:

bech32/ref/haskell/src/Codec/Binary/Bech32.hs

Line 85 in a4e672d

result = BSC.concat [BSC.map toLower hrp, BSC.pack "1", BSC.pack rest]

However, the checksum is calculated before the conversion to lower case takes place:

bech32/ref/haskell/src/Codec/Binary/Bech32.hs

Line 83 in a4e672d

let dat' = dat ++ bech32CreateChecksum hrp dat

This contradicts the Bech32 specification, which states:

"The lowercase form is used when determining a character's value for checksum purposes."

Therefore, if the original human-readable part contains one or more upper case characters:

1. the generated checksum will be inconsistent with the human-readable prefix of the output string
2. the output string will fail to decode.

Example

Consider the following two calls to bech32Encode, differing only in the case of the human-readable part:

> bech32Encode "test" []
> bech32Encode "TEST" []

Expected Behaviour

Both calls to bech32Encode should result in the same output string:

> bech32Encode "test" []
Just "test12hrzfj"
> bech32Encode "TEST" []
Just "test12hrzfj"
> bech32Encode "test" [] == bech32Encode "TEST" [] 
True

Actual Behaviour

The above calls to bech32Encode actually result in different output strings:

> bech32Encode "test" []
Just "test12hrzfj"
> bech32Encode "TEST" []
Just "test13jgcyw"
> bech32Encode "test" [] == bech32Encode "TEST" [] 
False

Attempting to decode the string produced by bech32Encode "TEST" [] results in Nothing:

> bech32Decode "test13jgcyw"
Nothing

Possibly incorrect bech32m test case

This test case is listed in BIP-350 as a valid bech32m: 11llllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllludsr8

However, it does not appear to obey the rules of 5-to-8 conversion of bech32. Beside its HRP and checksum, it contains 82 l characters, which are each converted to number 31 (binary 11111). Since each character will be interpreted as five bits, the result of the conversion is 410 1 bits.

This results in 2 1 bits padding, which does not meet the requirements of this sentence from BIP-173: Any incomplete group at the end MUST be 4 bits or less, MUST be all zeroes, and is discarded.

Please let me know whether the test case is wrong, or is the way I think about it is wrong. Thank you

Suggestion to start address with "btc" instead of "bc"

1 extra character is a worthwhile tradeoff to make things a lot more clear. People are already used to the symbols "btc", so it's much easier for people to understand that addresses starting with "btc1" are Bitcoin addresses.

We plan to use "ltc1" and "tltc1" for Litecoin and I'm sure other coins will do something similar.

LICENSE

The BIP is License: BSD-2-Clause, is this code the same?

For certain Bech32 strings, deleting or inserting a single character produces a string that is still valid

Overview

For certain Bech32 strings, deleting or inserting just a single character can produce a string that is still valid when tested against the reference implementations.

Implementations Tested

• Haskell reference implementation
• JavaScript reference implementation

Cases

There appear to be two main cases:

1. Insertion: if a valid Bech32 string has the suffix p, inserting a single q character immediately before the p will produce another valid Bech32 string.

2. Deletion: if a valid Bech32 string has the suffix qp, removing the q character will produce another valid Bech32 string.

These production rules can apparently be applied repeatedly, either by deleting many q characters, or by inserting many q characters, producing a valid Bech32 string after each step.

Examples

The string ii2134hk2xmat79tp is a valid Bech32 string, with:

• human-readable part ii2
• data part 34hk2xm
• checksum at79tp

Insertion

By inserting one or more q characters immediately before the final p character, we can produce more strings that are valid Bech32 strings:

• ii2134hk2xmat79tqp
• ii2134hk2xmat79tqqp
• ii2134hk2xmat79tqqqp
• ii2134hk2xmat79tqqqqp

Deletion

Conversely, by deleting one or more q characters located immediately before a final p character, we can go the other way. The following are all valid Bech32 strings:

• eyg5bsz1l2mrq5ypl40hqqqp
• eyg5bsz1l2mrq5ypl40hqqp
• eyg5bsz1l2mrq5ypl40hqp
• eyg5bsz1l2mrq5ypl40hp

Outstanding Question

It's currently unknown to us whether this is a property of the specification itself, or merely a feature of the reference implementations that we tested.

Background

We ran a suite of property tests against a modified version of the reference implementation, designed to simulate simple user errors such as omitting a character from, or inserting an extra character into, pseudo-randomly generated Bech32 strings.

Case handling inconsistencies in reference implementations

From an IRC discussion:

[cfields] sipa: the bip shows a test vector of 'A12UEL5L', which i presume to be a hrp of 'A' and empty data....
[cfields] It says "Encoders MUST always output an all lowercase Bech32 string".
[cfields] Confusingly, the c ref returns a failure on an uppercase HRP, but c++ returns an invalid encoding instead.
[cfields] I think the c++ ref needs to lc() the hrp input first, but the c ref leads me to believe that encoders should expect the hrp to already be lowercased.
[sipa] cfields: i think someone has ponted out that it's not entirely consistent
[sipa] either we alwaya assume the hrp is already lowercase
[sipa] or lc it
[cfields] well the bip specifies what decoders must not accept mixed case, maybe it would be worth amending to specify that either "encoders must not accept an uppercase hrp", or "encoders must first lowecase the hrp" ?
[cfields] either way, as-is, the c++ ref returns an incorrect encoding for bech32::encode('A', {})

I'm happy to PR a fix, but it's unclear what needs to be fixed. The c/c++ encoders (I haven't looked at the others) should either fail to encode an uppercase hrp character, or quietly convert internally first.

Hello, do you have a JAVA version?

Hello, I am using the Harmony ONE address to bech32 format, can you provide the Java or kotlin version of the code?

QR code comparison

Hi Pieter,

I got asked to add the QR code comparison.
I noticed you cleaned your git repo history up.

I couldn't make a pull request because of it.
But can you do a git cherry pick?
romanornr@408c7be

Safe usage in mainnet

Am creating a wallet for testnet and mainnet.
Am wondering is it safe to enable the use of bech32 addresses in mainnet now ?
I already asked this question in stackexchange but it look like nobody have any idea
What worries me is the 'draft' status of this BIP
Thanks a lot for your contribution !

bip72b payment requests and qrcodes

In alphanumeric qrcode encoding it is not possible to encode a bip72b – bitcoin:?r=https://dev/null – payment requests urls because ? and = are missed.

We could introduce a new bip72 URI to use alphanumeric encoding in qrcode payment requests

(It would be more like BITCOIN:*HTTPS://DEV/NULL)

Allow first bech32 character to be uppercase?

While I understand why Bech requires all upper or lower characters, I think the standard should still permit the first character to be uppercase as many mobile input devices will automatically make it so.

Explicitly allowing so in the standard will avoid developers from having to choose between usability and correctness. It also reduce the risk of having non-standard applications create confusion amongst users.