Vanitygen: Impossible addresses?

3

1

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?

Chuck R

Posted 2015-02-06T10:39:48.460

Reputation: 163

Answers

5

This is due to the "version" byte and the way bitcoin addresses are made 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.

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.

Jimmy Song

Posted 2015-02-06T10:39:48.460

Reputation: 7 067

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 – 2015-02-06T20:04:57.470

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 – 2015-02-06T20:08:08.293

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 – 2015-02-06T21:48:25.150

this should give you a better idea. Basically, it's encoding the public point (x,y) into a single byte array. – Jimmy Song – 2015-02-06T21:50:41.480

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 – 2015-02-06T23:07:54.463

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 – 2018-01-23T03:56:40.900

Asked: 2015-02-06T10:39:48.460

Viewed: 1 104 times

Active: 2019-01-20T12:47:07.550