Andrew Poelstra
Andrew Poelstra
If not I'm happy to remove it. It seemed like an odd thing to do, but the existing Rust code did it.
Removed. This did mean that we had to remove a couple test vectors (which are "invalid segwit addresses" according to BIP-173 and 350 but nonetheless valid bech32).
@leishman Sorta, yes. The signatures on the excess values are actually multisignatures between signer and receiver, but I didn't fully realize this when I wrote the paper, so I'm not...
@leishman Yes, pretty much. (Though note that addresses are neither identification nor authentication, and anyone using them as such are exposed to address substitution attacks.) Having said that, it's possible...
@leishman grin supercedes my implementation (because Peverell got much further than I had before publishing :P). I've been in contact with him.
Thanks! I think we'll redo the workshop branch once we've merged all of `new_complete` into master. Good that there's a workaround for now. In general we lack a good way...
Why is it illegal to decode? If we are going to do something other than "blocks of 93 characters, with the last one truncated" I'd rather try to make both...
> Any incomplete group at the end MUST be 4 bits or less Hah! I never noticed that this rule forbade certain lengths of bech32 strings. Very interesting. Ok, I...
I'm doubtful that mistakes here would actually be money-losing: people would decode an incorrect string (in fact, I think if they concatenate after u5->u8 they'll get a *wrong length* string,...
Relatedly, it would be nice to have a 3-letter HRP so that you can put e.g. `sss1` as the first group in the cryptosteel.