bech32 design

Date: December 22, 2017

Transcript By: Michael Folkson

Location: Bitcointalk

https://bitcointalk.org/index.php?topic=2624630.msg26762627#msg26762627

bech32 design

Bech32 is designed for human use and basically nothing else, the only consideration for QR codes is that all caps is also permitted.

For all your talk of human considerations you give a strong signal of having seldom actually used bitcoin addresses as a human. 1/3 type addresses are full of visually confusing characters and the case modulations are a pain to read and enter correctly. In actual testing transfering bech32 addresses to another person is on the order of 5x faster with bech32 due to errors being made even in careful usage of base58– more than the time itself transferring a base58 address is often insanely frustrating– you read it, and … nope, no idea where it’s wrong, only that it’s wrong -then you try reading the whole thing again and again and again.

Bech32 largely solves that both because it is MUCH easier to read correctly, less visually confusing, and because when you make just a single mistake it can tell you where it is.

The Base58 pattern with a fixed prefix is very visually distinct

BC is considerably more visually distinct; and it’s something the Bitcoin network can stick with– presumably forever.

cue for cryptocurrency

Some of the most popular alternative cryptocurrencies do not use base58, including Ethereum– it uses hex

trashing that visual distinction

Any new scheme would need to use a different prefix apart from 1 and 3, and would get confused with other cryptocurrencies. Morever, other cryptocurrencies squat 1 and 3 (bcash and litcoin p2sh for example) and, in fact, will falsely accept Bitcoin addresses and vice versa with disastrous consequences.

string with an approximate known length starting with 1 or 3 has worked for us so far.

It cannot be that, and even if it were, those values are now ambiguous.

If we have to learn it all over again, can it be something we already know? Why “BC” for Bitcoin? Could we have capital “BTC” or “XBT” followed by mixed case data.

BC is self explanatory, BTC gets confused with currency units and amounts, and it’s longer– more tying, more room for errors.

but now 2-letter acronyms for each cryptocurrency project.

The HRP can be any length, there doesn’t need to be any such 2-letter.

Please give us an encoding that spares us the confusion of having the lowercase letter L and the number 1 all in the same code. I’m sure I will

We did, the character set does not include “1”, “b”, “i”, or “o”; which is the unique selection which minimizes the number of visually confusing pairs, at least given the NIST visual confusion data we had available to us at the time. ..– I find it really disappointing that you wrote this long complaint without knowing even this….

A few weeks after publishing BIP173’s draft it some academic paper came out where they generated the visual/typing confusion data that I really wanted at the start but which no one had; – but by then people had wildly started deploying it, even before it had been extensively reviewed… this seems to be a reoccurring problem in Bitcoin. I haven’t rerun the optimizer with the new data, I really really doubt it would reject different characters (the new data is pretty similar) but the permutation might have been somewhat different with it.

Please let us keep our mixed case. Trust us, we’ve got capacity for it,

I don’t trust, I verify and the mixed case results in worse than a 2x slowdown sharing addresses between humans even when no errors are made, and it greatly increases the number of errors made too.

my glasses, maybe try both? It didn’t work?"… I hope it’s easy to see how this is actually more frustrating.

Mature software will tell you exactly where such errors are located, especially if they involve a charset mistake, but even errors beyond that. There should be very little hunt and peck with BECH32, and in my experience there isn’t any at all.

with a much greater damage coefficient than 1 over 4 billion, so changing how addresses look doesn’t reassure us or feel like progress, rather how it feels is it steepens our learning curve.

Your entire post seems to be motivated by a profound confusion about why this was motivated. A new address format was required for native segwit outputs, avoiding a new one isn’t possible. Given that we needed a new one we wanted to make it as user friendly as possible, and actually studied user behavior to achieve this.

Incidentally, the 1:2^32 odds of falsely sending to a wrong address is greatly increased by the many retries when people mess up base58 addresses and make speculative corrections… but bech32 wasn’t designed to improve the detection of wrong strings (in fact, it only achieves 1:2^30 protection against totally random correct-charset strings) but instead designed to be more pleasant to use by being able to hint where errors are located and not degrade on retry.

If you let us move forward with you on a new address format, while maintaining our beloved Base58 (our CPU’s still love us and are happy with the long division and the extra work parsing the mixed case),

embedded systems trying to implement bignum libraries for base conversion certainly don’t “love” it. (though this can be avoided with even more complex code).

Would keeping mixed case shorten the code enough to make extra room to pretend (for the sake of error correction) that each character has 64 possible symbols? We could dedicate another character or two to the checksum to make up for it.

No, it doesn’t work that way, and the mixed case is a massive slowdown in actual use by humans. Of course, computers don’t care– but computers don’t care – the addresses are for human friendlyness, not for computers.

Having two characters BC represent Bitcoin also feels political, as though it is an effort to pretend that there aren’t alt coins with significant merit.

First, Bitcoin invented this field and if you feel that its natural privileged from doing so is “political” then I really don’t see a need to continue discussion with you. If you don’t want to put Bitcoin first that’s your decision and not something I mind, but don’t you dare demand that people who have more or less dedicated their life to it to do worse work on Bitcoin in order to facilitate whatever competing systems that you prefer.

Secondly, we actually made significant design considerations specifically to facilitate altcoins. Earlier versions of the design restricted the HRP to the same character set as the data, and so there was no character set that wouldn’t have permitted many altcoins from using their favorite monikers (e.g. no LTC given our charset due to the use of L). We wanted implementer of multicurrency software to be able to use the same code for many systems; while we’re not going to degrade things for bitcoin we actually did go out of our way to design something that was very generic and inclusive– even though doing so is probably not the best competitive approach for Bitcoin… it probably would have been better to set it up so altcoins would require incompatible code so software would be less likely to implement support for them. Too bad you’re too blinded to see it.