Quote from: nullius on December 21, 2017, 12:03:06 PM

I will meet you halfway in positing that the human-readable prefix btc would be better than bc, at the expense of an extra character which transmits no data.

The HRP and data delimiter needs to be a character which is outside of the character set-- this is because the HRP can contain characters both in and outside of the charset, so to find the boundary we need the last character of it to be outside of the set. The delimiter must also must be alphanumeric to preserve single click copy in many environments (including browsers). So this left us with using one of bio1, or changing the character set to be more visually confusing and getting a different option. In the vast majority of contexts the prefix is completely fixed by the application usage, so there is no possibility of confusion in any case.

Quote

seems an homage to the old-style P2PKH addresses

Right, among the options it had that advantage and it was also the one that was least visually confusing.

Quote

that I hate it, I cant handle itI find it absurdly frustrating and error-prone.

This is what many people report, and even people that said they didn't mind it handled it much more slowly. My general experience from when we stared on this was that people who said mixed case wasn't an issue changed their mind after actually trying to convey an address view spoken word or writing it down by hand with pencil and paper. ... Either they had never done it before or had done it infrequently enough that they'd already repressed the traumatic memories. I don't doubt that there are some odd people out there which never have any trouble with it, but I haven't encountered anyone yet who doesn't when actually tested on it.

Quote

Ill admit, as a C programmer, I am a tiny bit annoyed by the Bech32 choice of alphabet. Its not in ASCII order! The stupendous inconvenience of a lookup table is required for decoding

the table and its use however can be one line of code. I think one line of code is a pretty good trade-off for improved error detection. The base conversion for bech32 and checksum code are each easily 1/10th the code/size of base58 handling too. I think the cost of a little lookup table is easily paid for by improvements in other areas.

(The mapping is such that the most likely confused characters tend to result in only a single bit-flip and the code is designed so that it is slightly stronger in those cases than advertised).

Quote

1. My regards to Pieter Wuille and Greg Maxwell: I can tell that an excruciatingly detailed thought process about Bitcoin address formats went into that bit of engineering. Somebody stayed up in the dark wee hours, pondering the philosophy of Bitcoin address formats. Somebody aspired to consummate perfection in the art of Bitcoin address formats. Well, you are probably also odd. Coming from me, take that as a compliment.

Thanks, including a lot of testing with both people and machines, several CPU decades went into the design of the error correcting code... and in fact the techniques even required to be able to measure their performance are themselves novel and probably publishable innovations. Not to mention extensive review and redesign with many other similarly crazy people. We understood that introducing a new address format is a big step that can't be done often, and thought it would be appropriate and acceptable to really work hard on it.