Bitcoin Addresses contain a check-value: extra data added on computed as a function of the rest so that mistakes are unlikely to be acceptable addresses. 1x and 3x addresses use a 32-bit cryptographic hash for their check value and as a result any given well formatted random address has roughly a 1 in 2^32 chance of being accepted.

But when users make mistakes they don’t generally produce random strings they tend to make typos where a small number of characters are replaced with alternatives which are visually similar, audibly similar, keyboard-position similar, or case variations. Transposition of adjacent characters is also more likely than random errors. 1x/3x addresses are designed with one improvement to likely errors: the base58 charset excludes a number of visually similar characters.

On average one of these likely errors is also only going to be accepted 1 in 2^32 times, but sometimes a given address is more vulnerable since the detection performance is only an average. E.g. you could have an address where there are one or more different places where a likely mistake could be made. This isn’t a practical concern, since these cases are unlikely, but it’s an area that could be improved on.

BIP173 introduced BC1x style addresses (also called bech32). BC1 addresses use a smaller character set that doesn’t have mixed case which completely eliminates one major cause of transcription errors. Like base-58 the bech32 character set also excludes some visually confusing characters (in addition to all the mixed case cases).

BC1 addresses also have a check value, but it is 30 bits instead of 32-bits. The 30-bit check in BC1 addresses, although shorter, is radically stronger than the old approach because it is constructed out of an error correcting code instead of a cryptographic hash.

The construction for BC1 addresses guarantees that up to 4 character errors or 4 transpositions in an address are always detected. 5 errors are also always detected if they’re all made among the most visually similar remaining characters. For more errors than are guaranteed the false acceptance rate approaches 1 in 2^30 as the number of errors goes up.

The error correction code based design of bech32 also means that applications can hint to users what characters they got wrong without a computationally expensive brute force search.

When we designed BIP173 we felt that 30-bits of protection against random errors was probably overkill, but we didn’t want to have error detection performance that was much worse than the old standard in any major respect.

If you model the user as making random mistakes and entering, say, 2.5% of the characters wrong on average (so one mistake expected per entered address) then bech32 gives that user protection better on average than a 39 bit random hash (so 1 in 2^39 wrong addresses they enter will be falsely accepted). Being more careful pays off too: if the user’s error rate is reduced to 0.1% the rate of accepted bad addresses drops to 1 in 2^60).

This graph shows the effective protection level as a function of the user’s error rate for Bech32, a 32-bit hash (like 1x addresses), and alternative error correcting code which we could have ended up with if we hadn’t taken so much care in designing bech32:

BC1 address also avoid errors in another way: People sometimes lose funds because a number of reckless/scammy altcoins have copied Bitcoin address format, so you can accidentally send bitcoins to an altcoin address. For the moment this doesn’t apply to BC1 address, and the prefix beginning with ‘BC’ hopefully will reduce the odds of it in the future. (Though sadly, it’s become trendy for more scammy cryptocurrencies to call themselves ‘bitcoin’ now, so perhaps not.)

Improved error detection is just one of many reasons users should prefer BC1 addresses these days.

Article First Published here