<p>Yes. Every byte sequence corresponds to one Base58 string. Every byte sequence also corresponds to one Base58Check string, which contains a 4-byte redundancy, a checksum.</p>
<p>And this 4-byte-code's only purpose is the detection of transmission errors (typos). Newer Bech32 addresses have a different kind of checksum allowing error correction, up to a certain level in addition to error detection.</p>

CC BY-SA 4.0
2023-08-06T14:51:16.880Z
So the chance for a missed typo is 1 in `2^32` as the checksum is 4 bytes in lenght?
Rene Pickhardt
CC BY-SA 4.0
2023-08-06T18:31:06.317Z
@RenePickhardt Approximately yes, in practice a little less than that because for example adding a character or removing a character *usually* changes the number of bytes decoded so the software would nevertheless reject it. As for changing a character, I suspect that changing the character after `1` sometimes causes likewise.
MCCCS
CC BY-SA 4.0
2021-01-31T09:59:46.453Z
2021-01-31T09:59:46.453Z
MCCCS
<p>I am reading the book Grokking Bitcoin by Manning 2019.</p>
<p>It first said, if John sends the token (bitcoin) to the cafe owner but made a typo in the cafe's address (the PKH), then that token is &quot;burned&quot; and gone forever. Nobody can use it whatsoever.</p>
<p>So to safeguard it, Base58check is used.  But Base58, like Base64, is merely to convert some numbers to different representation of characters, and can be converted back and forth freely by anybody.</p>
<p>But it seems like, what is at work to prevent the &quot;typo&quot; is not Base58, but that there is a 4 byte &quot;checksum&quot;, perhaps like some banks, when you tell them the account number, they have a one digit checksum which is the last digit of your account number, to see whether the checksum match.</p>
<p>So the Base58check really depends on this &quot;checksum&quot; to verify that you didn't make a typo, and the odds that you made a typo but the checksum still checks is by that 4 bytes, therefore is 32 bit and is 1 in 4 billion odds?  So it is not Base58 itself, but the &quot;check&quot; part or the &quot;checksum&quot;?</p>

<base58><base58check>
ELI5: is it true that Base58 doesn't prevent typo, but Base58check does, really because there is a checksum?
deeper-understanding
# ELI5: is it true that Base58 doesn't prevent typo, but Base58check does, really because there is a checksum?

(Asked by: username_0 on 2021-01-31)

I am reading the book Grokking Bitcoin by Manning 2019.

It first said, if John sends the token (bitcoin) to the cafe owner but made a typo in the cafe's address (the PKH), then that token is "burned" and gone forever. Nobody can use it whatsoever.

So to safeguard it, Base58check is used. But Base58, like Base64, is merely to convert some numbers to different representation of characters, and can be converted back and forth freely by anybody.

But it seems like, what is at work to prevent the "typo" is not Base58, but that there is a 4 byte "checksum", perhaps like some banks, when you tell them the account number, they have a one digit checksum which is the last digit of your account number, to see whether the checksum match.

So the Base58check really depends on this "checksum" to verify that you didn't make a typo, and the odds that you made a typo but the checksum still checks is by that 4 bytes, therefore is 32 bit and is 1 in 4 billion odds? So it is not Base58 itself, but the "check" part or the "checksum"?

**Tags:** base58, base58check


---

## 1 answers

### Answer by username_1 on 2021-01-31. Score: 3

Yes. Every byte sequence corresponds to one Base58 string. Every byte sequence also corresponds to one Base58Check string, which contains a 4-byte redundancy, a checksum.

And this 4-byte-code's only purpose is the detection of transmission errors (typos). Newer Bech32 addresses have a different kind of checksum allowing error correction, up to a certain level in addition to error detection.

> **Comments:**
> **username_2**: So the chance for a missed typo is 1 in `2^32` as the checksum is 4 bytes in lenght?  
> **username_1**: @username_2 Approximately yes, in practice a little less than that because for example adding a character or removing a character *usually* changes the number of bytes decoded so the software would nevertheless reject it. As for changing a character, I suspect that changing the character after `1` sometimes causes likewise.  

---

