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

[jonathanknowles]

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

[real-or-random]

I haven't looked at the details but seems related to #38.

[jonathanknowles]

I've created a PR that fixes the issue here: #50