<p>The checksum of Base58Check encoding is simply a truncated hash of the rest of the bytes. This means there is no recovery algorithm other than just brute-forcing until the hash matches.</p>
<p>That is one of the big advantages of the Bech32 address format proposed in <a href="https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki" rel="nofollow noreferrer">BIP-173</a>. It uses an algebraic BCH code which can actually correct errors rather than just detect them, and has better error detection/correction properties than Base58Check.</p>
<p>In both cases, however, it is strongly discouraged for code to perform any address recovery itself. You should report to the user that errors exist, and let the user fix them. Otherwise, you risk loss of funds.</p>

CC BY-SA 4.0
2022-02-02T01:09:42.273Z
Hmm the checksum is completely redundant so if you get an address with the last 4 bytes missing you could just recalculate the checksum no? You don’t have to brute force anything
Mike D
CC BY-SA 4.0
2022-02-02T02:18:31.360Z
If the checksum is the only thing missing, yes. But then you have no guarantee that the rest of the address is valid. If the checksum is missing that is quite concerning. So you should certainly not just add a checksum and use it.
meshcollider
CC BY-SA 4.0
2022-02-02T02:20:26.233Z
Note that an address without its checksum is the same as just sharing the public key hash directly.
meshcollider
CC BY-SA 4.0
2022-02-02T08:12:11.080Z
No worries, my question is basically "how vain can a vanity address get", I hope I didn't XY-problem this too much  But as @Mike stated, my question is mainly about omitting the checksum. In a power-of-two base this would be trivial since the checksum would then be exactly the last few bytes, but in base58 there's a mixture with higher order bytes which seems to render this a bit more complicated (though this might just be my lack of sleep...)
Tobias Kienzler
CC BY-SA 4.0
2022-02-02T12:45:08.100Z
@TobiasKienzler you can omit up to log58(2^32) = 5.46 digits in base 58 and not lose any information as you said so basically up to 5 digits
Mike D
CC BY-SA 4.0
2022-02-02T14:02:38.103Z
@MikeD Exactly, that's the _theory_. I'm just unsure about the practical implication, if possible. I'll give an actual algorithm a shot later 
Tobias Kienzler
CC BY-SA 4.0
2022-02-01T22:07:04.600Z
2022-02-01T22:07:04.600Z
meshcollider
<p>Since P2PKH and P2SH addresses use <a href="https://en.bitcoin.it/wiki/Base58Check_encoding" rel="nofollow noreferrer">Base58Check_encoding</a>, the 4 byte checksum appended in binary contains some redundancy. Strictly mathematically speaking, those 4 bytes correspond to ca. floor(log(2^32)/log(58)+1) = 6 base58 &quot;digits&quot; (but 6 base58-digits encode 36 bits, i.e. probably only 5 instead of 6 can be omitted). But is this sound? In a 2^n base this would be trivial, but base 58 basically influences all bytes... Is there a recovery algorithm?</p>

<address><public-key><base58><encoding><checksum>
How much can be stripped of a base58 address in a recoverable way?
Tobias Kienzler
# How much can be stripped of a base58 address in a recoverable way?

(Asked by: username_0 on 2022-02-01)

Since P2PKH and P2SH addresses use [Base58Check\_encoding](https://en.bitcoin.it/wiki/Base58Check_encoding), the 4 byte checksum appended in binary contains some redundancy. Strictly mathematically speaking, those 4 bytes correspond to ca. floor(log(2^32)/log(58)+1) = 6 base58 "digits" (but 6 base58-digits encode 36 bits, i.e. probably only 5 instead of 6 can be omitted). But is this sound? In a 2^n base this would be trivial, but base 58 basically influences all bytes... Is there a recovery algorithm?

**Tags:** address, public-key, base58, encoding, checksum


---

## 1 answers

### Answer by username_1 on 2022-02-01. Score: 2

The checksum of Base58Check encoding is simply a truncated hash of the rest of the bytes. This means there is no recovery algorithm other than just brute-forcing until the hash matches.

That is one of the big advantages of the Bech32 address format proposed in [BIP-173](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki). It uses an algebraic BCH code which can actually correct errors rather than just detect them, and has better error detection/correction properties than Base58Check.

In both cases, however, it is strongly discouraged for code to perform any address recovery itself. You should report to the user that errors exist, and let the user fix them. Otherwise, you risk loss of funds.

> **Comments:**
> **username_2**: Hmm the checksum is completely redundant so if you get an address with the last 4 bytes missing you could just recalculate the checksum no? You don’t have to brute force anything  
> **username_1**: If the checksum is the only thing missing, yes. But then you have no guarantee that the rest of the address is valid. If the checksum is missing that is quite concerning. So you should certainly not just add a checksum and use it.  
> **username_1**: Note that an address without its checksum is the same as just sharing the public key hash directly.  
> **username_0**: No worries, my question is basically "how vain can a vanity address get", I hope I didn't XY-problem this too much  But as @username_2 stated, my question is mainly about omitting the checksum. In a power-of-two base this would be trivial since the checksum would then be exactly the last few bytes, but in base58 there's a mixture with higher order bytes which seems to render this a bit more complicated (though this might just be my lack of sleep...)  
> **username_2**: @username_0 you can omit up to log58(2^32) = 5.46 digits in base 58 and not lose any information as you said so basically up to 5 digits  
> **username_0**: @username_2 Exactly, that's the _theory_. I'm just unsure about the practical implication, if possible. I'll give an actual algorithm a shot later   

---

