<p>This is due to the "version" byte and the way <a href="https://en.bitcoin.it/wiki/Base58Check_encoding" rel="noreferrer">bitcoin addresses are made</a> with base58.</p>

<p>The procedure is pretty straightforward:</p>

<ol>
<li>the version byte</li>
<li>the RIPEMD160 of the SHA256 (known as HASH160) of the sec format of the public key (don't worry too much about this part, just know it's 20 bytes long)</li>
<li>the checksum (4 bytes long)</li>
</ol>

<p>Concatenate these and you have a 1 + 20 + 4 = 25 byte string which then gets encoded into a base58 string to form the bitcoin address. Note that parts 2 or 3 can be pretty much anything, but the version byte is specific to the network.</p>

<p>For your case, the version byte of testnet is 0x6f.</p>

<p>The documented procedure for calculating base58 is <a href="https://en.bitcoin.it/wiki/Base58Check_encoding" rel="noreferrer">here</a>.</p>

<p>Here is a simple python program to demonstrate how this is done:</p>

<pre><code>alphabet = "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz"
def b58(x):
    a = ""
    while x &gt; 0:
        x, r = divmod(x,58)
        a += alphabet[r]
    return a[::-1]
print b58(0x6f0000000000000000000000000000000000000000)
print b58(0x6fffffffffffffffffffffffffffffffffffffffff)
</code></pre>

<p>The result of this program is this:</p>

<pre><code>mfWxJ45yp2SFn7UciZyNpvDKrzbhuzkU7H
n4rZHAPGXCu8bYchjzJhK3V7VVredELJRc
</code></pre>

<p>That is actually the range of possible addresses within testnet. This is because anything before <code>mfWxJ45yp2SFn7UciZyNpvDKrzbhuzkU7H</code> would result in the first byte being 0x6e and anything after <code>n4rZHAPGXCu8bYchjzJhK3V7VVredELJRc</code> would result in the first byte being 0x70. Running vanitygen should confirm:</p>

<pre><code>$ vanitygen -T mfWxJ3
Prefix 'mfWxJ3' not possible
$ vanitygen -T mfWxJ4
[...]
</code></pre>

<p>It's important to keep the version number in mind when generating vanity addresses for this reason.</p>

CC BY-SA 3.0
2015-02-06T20:04:57.470Z
So, the resulting Base56Check string is in numerical order (reverse of the order it is determined). When creating an offline address, is the payload for RIPEMD160(SHA256()) the hex (unaltered) public key?
Chuck R
CC BY-SA 3.0
2015-02-06T20:08:08.293Z
It's the sec format of the public key, which is either compressed or uncompressed which goes into the HASH160. R is actually before f in the Base58 alphabet. The order of the alphabet is 123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz.
Jimmy Song
CC BY-SA 3.0
2015-02-06T21:48:25.150Z
Yep, R before f, I realized the stupidity of that comment when I made it -- edited it out ;). I still don't understand what you mean by "sec" format? Can't be "secret", then it wouldn't be a public key...
Chuck R
CC BY-SA 3.0
2015-02-06T21:50:41.480Z
[this](http://blog.richardkiss.com/?p=371) should give you a better idea. Basically, it's encoding the public point (x,y) into a single byte array.
Jimmy Song
CC BY-SA 3.0
2015-02-06T23:07:54.463Z
Ah, thank you very much! While that particular page didn't answer my question, it helped me find this: https://tools.ietf.org/html/rfc5915
Chuck R
CC BY-SA 3.0
2018-01-23T03:56:40.900Z
That particular code doesn't produce the result specified. This is because the inputs don't include the 4 byte checksum. Add a further 8 zeroes or 8 f's to the input to receive the stated results.
 mynt
CC BY-SA 3.0
2015-02-06T16:47:28.933Z
2015-02-06T16:47:28.933Z
Jimmy Song
<p>I'm currently attempting to modify Vanitygen to suit a particular purpose. However, I'm running into an issue with "impossible" addresses. For example, from the stock Vanitygen available on Github I get this output:</p>

<pre><code>./vanitygen -T mR
Prefix 'mR' not possible
Hint: valid testnet addresses begin with "m" or "n"
</code></pre>

<p>While the following works:</p>

<pre><code>./vanitygen -T m
Difficulty: 1
Pattern: m
Address: mh8e8yUtsmhCm6PTkuHV85ozEV5iNibmbp
Privkey: ***************(doesn't matter)
</code></pre>

<p>I get similar results for this set of options:</p>

<pre><code>./vanitygen -F script 3Ro
Prefix '3Ro' not possible
Hint: valid bitcoin script addresses begin with a "3"
</code></pre>

<p>and</p>

<pre><code>./vanitygen -F script 3R
Difficulty: 836
Pattern: 3R
P2SHAddress: 3R1jUHTrESWgCC812LrgwHErc9Y3UL7XeL
Address: *********(doesn't matter)
Privkey: *********(doesn't matter)
</code></pre>

<p>So, I'm trying to determine why Vanitygen is saying that these particular prefixes are not possible. For both of these failures, the failure occurs within get_prefix_ranges(). However, this isn't a programming question, necessarily. What I'm trying to uncover is some underlying principle that I may be missing that would render these particular prefixes impossible.</p>

<p>Perhaps a couple of questions may help me answer this myself:</p>

<p>When Base58Check encoding the version+publickey+checksum, how exactly is the encoding processed? Is the input broken into 6-byte words and then converted into Base58 format (seems implausible because you could theoretically have something like 111111 (binary) in the checksum that would be > 58). Or, is the whole version+pubkey+checksum converted to a BigNumber and then essentially Mod 58'd for each character.</p>

<p>If the latter is the case (which seems probable), in what order does this occur? Using the example of 80FAFBFC (2163932156 decimal): </p>

<pre><code>x = 2163932156
result[0] = x % 58 = 6
x = floor(x / 58) = 37309175
result[1] = x % 58 = 37
x = floor(x / 58) = 643261
result[2] = x % 58 = 41
x = floor(x / 58) = 11090
result[3] = x % 58 = 12
x = floor(x / 58) = 191
result[4] = x % 58 = 17
x = floor(x / 58) = 3
result[5] = 3

result = [6, 37, 41, 12, 17, 3]
Convert to Base58 values:
result = [7,  e,  i,  D,  J, 4]
</code></pre>

<p>Would the result be displayed as: 7eiDJ4 or 4JDie7?</p>

<vanitygen>
Vanitygen: Impossible addresses?
Chuck R
# Vanitygen: Impossible addresses?

(Asked by: username_0 on 2015-02-06)

I'm currently attempting to modify Vanitygen to suit a particular purpose. However, I'm running into an issue with "impossible" addresses. For example, from the stock Vanitygen available on Github I get this output:

```
./vanitygen -T mR
Prefix 'mR' not possible
Hint: valid testnet addresses begin with "m" or "n"

```

While the following works:

```
./vanitygen -T m
Difficulty: 1
Pattern: m
Address: mh8e8yUtsmhCm6PTkuHV85ozEV5iNibmbp
Privkey: ***************(doesn't matter)

```

I get similar results for this set of options:

```
./vanitygen -F script 3Ro
Prefix '3Ro' not possible
Hint: valid bitcoin script addresses begin with a "3"

```

and

```
./vanitygen -F script 3R
Difficulty: 836
Pattern: 3R
P2SHAddress: 3R1jUHTrESWgCC812LrgwHErc9Y3UL7XeL
Address: *********(doesn't matter)
Privkey: *********(doesn't matter)

```

So, I'm trying to determine why Vanitygen is saying that these particular prefixes are not possible. For both of these failures, the failure occurs within get\_prefix\_ranges(). However, this isn't a programming question, necessarily. What I'm trying to uncover is some underlying principle that I may be missing that would render these particular prefixes impossible.

Perhaps a couple of questions may help me answer this myself:

When Base58Check encoding the version+publickey+checksum, how exactly is the encoding processed? Is the input broken into 6-byte words and then converted into Base58 format (seems implausible because you could theoretically have something like 111111 (binary) in the checksum that would be > 58). Or, is the whole version+pubkey+checksum converted to a BigNumber and then essentially Mod 58'd for each character.

If the latter is the case (which seems probable), in what order does this occur? Using the example of 80FAFBFC (2163932156 decimal):

```
x = 2163932156
result[0] = x % 58 = 6
x = floor(x / 58) = 37309175
result[1] = x % 58 = 37
x = floor(x / 58) = 643261
result[2] = x % 58 = 41
x = floor(x / 58) = 11090
result[3] = x % 58 = 12
x = floor(x / 58) = 191
result[4] = x % 58 = 17
x = floor(x / 58) = 3
result[5] = 3

result = [6, 37, 41, 12, 17, 3]
Convert to Base58 values:
result = [7,  e,  i,  D,  J, 4]

```

Would the result be displayed as: 7eiDJ4 or 4JDie7?

**Tags:** vanitygen


---

## 1 answers

### Answer by username_1 on 2015-02-06. Score: 5 | Accepted answer

This is due to the "version" byte and the way [bitcoin addresses are made](https://en.bitcoin.it/wiki/Base58Check_encoding) with base58.

The procedure is pretty straightforward:

1. the version byte
2. the RIPEMD160 of the SHA256 (known as HASH160) of the sec format of the public key (don't worry too much about this part, just know it's 20 bytes long)
3. the checksum (4 bytes long)

Concatenate these and you have a 1 + 20 + 4 = 25 byte string which then gets encoded into a base58 string to form the bitcoin address. Note that parts 2 or 3 can be pretty much anything, but the version byte is specific to the network.

For your case, the version byte of testnet is 0x6f.

The documented procedure for calculating base58 is [here](https://en.bitcoin.it/wiki/Base58Check_encoding).

Here is a simple python program to demonstrate how this is done:

```
alphabet = "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz"
def b58(x):
    a = ""
    while x > 0:
        x, r = divmod(x,58)
        a += alphabet[r]
    return a[::-1]
print b58(0x6f0000000000000000000000000000000000000000)
print b58(0x6fffffffffffffffffffffffffffffffffffffffff)

```

The result of this program is this:

```
mfWxJ45yp2SFn7UciZyNpvDKrzbhuzkU7H
n4rZHAPGXCu8bYchjzJhK3V7VVredELJRc

```

That is actually the range of possible addresses within testnet. This is because anything before `mfWxJ45yp2SFn7UciZyNpvDKrzbhuzkU7H` would result in the first byte being 0x6e and anything after `n4rZHAPGXCu8bYchjzJhK3V7VVredELJRc` would result in the first byte being 0x70. Running vanitygen should confirm:

```
$ vanitygen -T mfWxJ3
Prefix 'mfWxJ3' not possible
$ vanitygen -T mfWxJ4
[...]

```

It's important to keep the version number in mind when generating vanity addresses for this reason.

> **Comments:**
> **username_0**: So, the resulting Base56Check string is in numerical order (reverse of the order it is determined). When creating an offline address, is the payload for RIPEMD160(SHA256()) the hex (unaltered) public key?  
> **username_1**: It's the sec format of the public key, which is either compressed or uncompressed which goes into the HASH160. R is actually before f in the Base58 alphabet. The order of the alphabet is 123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz.  
> **username_0**: Yep, R before f, I realized the stupidity of that comment when I made it -- edited it out ;). I still don't understand what you mean by "sec" format? Can't be "secret", then it wouldn't be a public key...  
> **username_1**: [this](http://blog.richardkiss.com/?p=371) should give you a better idea. Basically, it's encoding the public point (x,y) into a single byte array.  
> **username_0**: Ah, thank you very much! While that particular page didn't answer my question, it helped me find this: https://tools.ietf.org/html/rfc5915  
> **username_2**: That particular code doesn't produce the result specified. This is because the inputs don't include the 4 byte checksum. Add a further 8 zeroes or 8 f's to the input to receive the stated results.  

---

