On Tuesday, December 8, 2020 9:39 AM, Ryan Grant <bitcoin-...@rgrant.org> wrote:
> It looks like a good strategy for a bech32 library that is external to > Bitcoin Core would be: > > - Default to the new M, under the same bech32 brand. > - Provide an interface to explicitly use both M=1 and M=0x2bc830a3. > - If decoding fails, throw an error; but in constructing that error > inform whether the other M would have succeeded. > > - Provide an interface for a BIP173 implementation to peek at the > witness version byte of the data part, which may also involve > sanity-checking that byte for errors using a BIP173-specific > understanding of the appropriate checksum. I think there are two possible interfaces that make sense: - Have the caller explicitly specify whether they want bech32 or bech32m (which someone - I think Rusty? - started using in reference to this new code and I'm going to adopt now). - Have the bech32 decoding function return a tristate (failed, valid as bech32, valid as bech32m). No string is ever valid as both, so there is no loss of information here. The former is a bit cleaner, and also the only real choice if error location hinting is desired. The second is more efficient if decoding twice is a performance concern. Cheers, -- Pieter _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
