<p>Iterate from the beginning until you reach a non-zero byte. Base58 encode the non-zero byte and the following, and add <code>1</code>s before the base58 string you made for each initial one zero byte (<code>0x00</code>) you counted.</p>
<p>Zero bytes after the first non-zero byte don't need special treatment.</p>
<p>For example, <code>[0, 13, 36]</code>, is encoded as <code>1211</code> since the value is <code>1*58^2</code> and <code>1</code> in base58 alphabet is <code>2</code>. From here, you see that if it's a multiple of 58, no special treatment is needed since the encoding is big endian and the <code>1</code>s caused by 58's powers are <em>automatically appended to the back</em></p>

CC BY-SA 4.0
2021-01-24T14:58:13.330Z
That's the part that *is* explained...and I explained that in my question. What do I do when the data becomes evenly divisible by 58 "too soon"? Just trim the leading 0s?
Robherc KV5ROB
CC BY-SA 4.0
2021-01-24T15:00:30.490Z
"the data is encoded to avoid having leading 0s, except to represent full '0' bytes in then input."
Robherc KV5ROB
CC BY-SA 4.0
2021-01-24T15:22:04.553Z
@RobhercKV5ROB OK, updated
MCCCS
CC BY-SA 4.0
2021-01-24T15:30:58.693Z
Ok, if there's no special treatment given, just divide modulo 58 until you reach 0, then my base58 conversion code must not be the culprit....**scratches head** I wrote my own offline cold-wallet generator using 4 passwords to generate a repeatable private key (i.e. same 4 passwords will always generate same private key) and it has worked perfectly 99% of the time. Unfortunately, 1 key I generated (WIF format) threw a "hash check failed" type error when I checked it against 3 known reliable wallet address (from private key) generators.
Robherc KV5ROB
CC BY-SA 4.0
2021-01-24T17:02:09.700Z
@RobhercKV5ROB You can verify your Base58 implementation by entering the byte sequence to be encoded to box 8 here: https://gobittest.appspot.com/Address This website is useful because you can also enter the private key (assumming it has no money) and it'll show you all the steps so you can find the culprit
MCCCS
CC BY-SA 4.0
2021-01-24T14:49:50.017Z
2021-01-24T15:22:00.327Z
2021-01-24T15:22:00.327Z
MCCCS
<p>I'm trying to more fully understand the base58check encoding algorithm.</p>
<p>Unfortunately, I keep running into a problem with how to handle a situation where the base58 value of an input would have leading 0's (1's in base58).
Everywhere I find any information about this online, it simply states that &quot;the data is encoded to avoid having leading 0s, except to represent full '0' bytes in then input.&quot;</p>
<p>What I need to understand is:
What is changed in the data (input or output) to avoid/correct this situation in the output string?</p>

<base58><base58check>
How to handle leading 0's (b58 1's) when base58check encoding
Robherc KV5ROB
# How to handle leading 0's (b58 1's) when base58check encoding

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

I'm trying to more fully understand the base58check encoding algorithm.

Unfortunately, I keep running into a problem with how to handle a situation where the base58 value of an input would have leading 0's (1's in base58).
Everywhere I find any information about this online, it simply states that "the data is encoded to avoid having leading 0s, except to represent full '0' bytes in then input."

What I need to understand is:
What is changed in the data (input or output) to avoid/correct this situation in the output string?

**Tags:** base58, base58check


---

## 1 answers

### Answer by username_1 on 2021-01-24. Score: 1 | Accepted answer

Iterate from the beginning until you reach a non-zero byte. Base58 encode the non-zero byte and the following, and add `1`s before the base58 string you made for each initial one zero byte (`0x00`) you counted.

Zero bytes after the first non-zero byte don't need special treatment.

For example, `[0, 13, 36]`, is encoded as `1211` since the value is `1*58^2` and `1` in base58 alphabet is `2`. From here, you see that if it's a multiple of 58, no special treatment is needed since the encoding is big endian and the `1`s caused by 58's powers are *automatically appended to the back*

> **Comments:**
> **username_0**: That's the part that *is* explained...and I explained that in my question. What do I do when the data becomes evenly divisible by 58 "too soon"? Just trim the leading 0s?  
> **username_0**: "the data is encoded to avoid having leading 0s, except to represent full '0' bytes in then input."  
> **username_1**: @username_0 OK, updated  
> **username_0**: Ok, if there's no special treatment given, just divide modulo 58 until you reach 0, then my base58 conversion code must not be the culprit....**scratches head** I wrote my own offline cold-wallet generator using 4 passwords to generate a repeatable private key (i.e. same 4 passwords will always generate same private key) and it has worked perfectly 99% of the time. Unfortunately, 1 key I generated (WIF format) threw a "hash check failed" type error when I checked it against 3 known reliable wallet address (from private key) generators.  
> **username_1**: @username_0 You can verify your Base58 implementation by entering the byte sequence to be encoded to box 8 here: https://gobittest.appspot.com/Address This website is useful because you can also enter the private key (assumming it has no money) and it'll show you all the steps so you can find the culprit  

---

