<p>Base58 check encoding is really just a base conversion. It follows the standard base conversion algorithm in mathematics.</p>

<p>Right before we perform the base conversion, we will have a sequence of 38 bytes. It's <code>0x80</code> + 32 byte private key + 1 byte compression indicator + 4 bytes checksum. For the encoding itself, these 38 bytes are interpreted as a very large number, and then a base 58 version of that number is computed.</p>

<p>Let's look at our number in hexadecimal (base 16). The constraints we have mean that the number will be at least <code>0x0x8000000000000000000000000000000000000000000000000000000000000000000000000000</code> and at most <code>0x80ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff</code>. Now in base 58, these two numbers are <code>KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU73NTmk4WB</code> and <code>L5oLkpV3aqBjhki6LmvChTCq73v9gyymzzMpBbhDLjDpKhfJuTe6</code>.</p>

<p>Since every possible value that can be encoded falls between those two base 58 numbers, all possible values that can be encoded must begin with a K or L.</p>

CC BY-SA 4.0
2020-05-02T06:28:00.963Z
2020-05-02T06:28:00.963Z
Ava Chow
<p>According to <a href="https://en.bitcoin.it/wiki/Wallet_import_format" rel="nofollow noreferrer">https://en.bitcoin.it/wiki/Wallet_import_format</a>,
the bitcoin private wif format key is create by below step.
And it says that the compressed wif key always start with 'K' or 'L',
this mean 80+private-key+01/ mod 58' last result is always 18 or 19.
I know the big number mod 58 will result in 0-57,
why the last remainder of wif key mod 58 always is 18 or 19 
Would someone give me Mathematical Proof of this?</p>

<pre><code> #1 take a private key
 priv='d7c9e36a4d31039d4b94a43246a4a5f0767f2f55ef9a359901c82c41fb1e4bff'
 compressed='01'

 #2 add version
 version='80' #mainnet
 priv=version+priv+compressed

 #3 perform double hash-256 of priv in step#2
 checksum=dhash256(priv.decode('hex'))

 #4 get first 4 bytes for checksum
 checksum=checksum.encode('hex')[0:8]

 #5 add checksum to priv in step#2
 wifhash=priv+checksum

 #6 final bash58encode
 wif= b58encode(wifhash.decode('hex'))

 # compressed --&gt; K or L
 print wif

 #compressed: L4TB9Z3dXeKW4tyF7EVqbczrEA5hjSdjG1QvBd1CeYTQHm2YincA

</code></pre>

<wallet-import-format>
Why bitcoin private key WIF format always be started in K or L?
kinjia
# Why bitcoin private key WIF format always be started in K or L?

(Asked by: username_0 on 2020-05-02)

According to <https://en.bitcoin.it/wiki/Wallet_import_format>,
the bitcoin private wif format key is create by below step.
And it says that the compressed wif key always start with 'K' or 'L',
this mean 80+private-key+01/ mod 58' last result is always 18 or 19.
I know the big number mod 58 will result in 0-57,
why the last remainder of wif key mod 58 always is 18 or 19
Would someone give me Mathematical Proof of this?

```
 #1 take a private key
 priv='d7c9e36a4d31039d4b94a43246a4a5f0767f2f55ef9a359901c82c41fb1e4bff'
 compressed='01'

 #2 add version
 version='80' #mainnet
 priv=version+priv+compressed

 #3 perform double hash-256 of priv in step#2
 checksum=dhash256(priv.decode('hex'))

 #4 get first 4 bytes for checksum
 checksum=checksum.encode('hex')[0:8]

 #5 add checksum to priv in step#2
 wifhash=priv+checksum

 #6 final bash58encode
 wif= b58encode(wifhash.decode('hex'))

 # compressed --> K or L
 print wif

 #compressed: L4TB9Z3dXeKW4tyF7EVqbczrEA5hjSdjG1QvBd1CeYTQHm2YincA

```

**Tags:** wallet-import-format


---

## 1 answers

### Answer by username_1 on 2020-05-02. Score: 9

Base58 check encoding is really just a base conversion. It follows the standard base conversion algorithm in mathematics.

Right before we perform the base conversion, we will have a sequence of 38 bytes. It's `0x80` + 32 byte private key + 1 byte compression indicator + 4 bytes checksum. For the encoding itself, these 38 bytes are interpreted as a very large number, and then a base 58 version of that number is computed.

Let's look at our number in hexadecimal (base 16). The constraints we have mean that the number will be at least `0x0x8000000000000000000000000000000000000000000000000000000000000000000000000000` and at most `0x80ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff`. Now in base 58, these two numbers are `KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU73NTmk4WB` and `L5oLkpV3aqBjhki6LmvChTCq73v9gyymzzMpBbhDLjDpKhfJuTe6`.

Since every possible value that can be encoded falls between those two base 58 numbers, all possible values that can be encoded must begin with a K or L.


---

