< sdaftuar>
cfields: if you have a chance, i could use advice on #11534 -- i needed to write a unit test where i manipulated the nodes in a CConnman, and I didn't know what the right way to do that was.
< jtimon>
so, the other day we discussed the size of txs in tests is not deterministic because the size of the signatures may vary with the private key (yuck, but thanks aj again for pointing it out, I was hopelessly reading coin selection code)
< cfields>
sipa: around? I'm finally re-implementing bech32 to learn/test, and there's an inconsistency that's tripping me up.
< sipa>
cfields: ok?
< sipa>
i'm half here
< cfields>
sipa: hmm, ok. Just noticed something. I'll form a solid question, and maybe some percentage of you will still be around :)
< 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', {})