Fix Bech32 decoder + encoder

[jonathanknowles]

Issue Number

This PR fixes the following issues:

• Bech32 decoder fails for certain valid Bech32 strings. #311 (Bech32 decoder fails for certain known-to-be-valid Bech32 strings)
• Bech32 encoder can be coerced into producing a string that can't be decoded #314 (Bech32 encoder can be coerced into producing a string that can't be decoded)

Overview

For #311:

• Adds a new type DataPart, which wraps [Word5].
• Changes the types of decode and encode so that they operate on DataPart instead of ByteString.
• Ensures that the round-trip relationship between encode and decode is preserved.
• Provides auxilliary functions dataPartFromBytes and dataPartToBytes to convert to (and from) ByteString and DataPart:
  • dataPartFromBytes pads with trailing zeros where appropriate.
  • dataPartToBytes trims trailing zeros where appropriate.
• Provides unit tests to ensure that all reference Bech32 strings mentioned in the Bech32 standard can be decoded successfully.

For #314:

• Reworks smart constructors for HumanReadablePart and DataPart so that inputs are always converted to lower case.

[KtorZ]

The change itself looks good, a few remarks about style & infinite shrinkers 😅

[KtorZ]

Looks good. Are you planning on making a PR upstream to fix the reference implementation ?

[jonathanknowles]

Looks good. Are you planning on making a PR upstream to fix the reference implementation ?

I'm happy to do that, as it's relatively simple to fix. But perhaps we should wait for upstream to confirm first? I've raised an issue here: sipa/bech32#49

[KtorZ]

Well, looking at the JavaScript implementation on bitcoinjs/bech32

We have the following behavior:

> bech32.encode('test', [])
'test12hrzfj'
> bech32.encode('Test', [])
'test12hrzfj'
> bech32.encode('TEST', [])
'test12hrzfj'
> bech32.encode('TEsT', [])
'test12hrzfj'
> bech32.encode('TesT', [])
'test12hrzfj'

> bech32.decode("test12hrzfj")
{ prefix: 'test', words: [] }
> bech32.decode("test13jgcyw")
Error: Invalid checksum for test13jgcyw

which is quite aligned to what we now expect. This seems like a fair indication that there's indeed a bug in the Haskell reference implementation.