Vanitygen: Vanity bitcoin address generator/miner [v0.22]

[flatfly]

Nvm, it was actually just a misunderstanding on my part.

EDIT: wasn't easy, but I found the answer I was looking for here:
 http://sourceforge.net/mailarchive/forum.php?thread_name=CAPg%2BsBhDFCjAn1tRRQhaudtqwsh4vcVbxzm%2BAA2OuFxN71fwUA%40mail.gmail.com&forum_name=bitcoin-development

[1713984889]

1713984889

[1713984889]

1713984889

[1713984889]

1713984889

[malevolent]

Well then I guess I have no idea.  I'm a C++ guy in my day job but I haven't looked into the fine details of the BTC algos.

OP hasn't posted for over a month so I'm not sure he's around anymore.

He didn't post from August 2011 till July 2012, he has a life I guess, but I'm sure he hasn't abandoned his useful project.

[nibor]

samr7,
Is it possible for you to comment a little on what the difficulty number represents and how it's calculated. I tried looking thru the code and figuring it out but BN math and probability is definitely not my forte. I ended up being pretty confused.

I'd like to be able to estimate the probability for a prefix pattern in my own code without running vanitygen - if not perfect mathematically then a rough time estimate would work.

Hi BkkCoins,

Difficulty is the number of keys that have to be checked, on average, to find a match.

The simplest way to do this is to have a table of prefix difficulties, and for each character after the beginning of the prefix, multiply by 58.  For this, you'd have something like:

11 = 256
12-1P = 22
1Q = 65
1R-1z = 1353

So, 1Abc = 22 x 58 x 58 = 74008, and 1egg = 1353 x 58 x 58 = 4551492, which are very close to the exact difficulties.  This scheme wouldn't be very accurate for multiple leading 1s, and certain suffixes of 1Q, without special handling of those cases.


The exact, but more complicated way to do this is to follow the formula:

Difficulty = (Total addresses) / (Matching addresses)

The tricky part is figuring out the number of matching addresses.  If your keys were 10-digit base-10 numbers, and you wanted to find everything with a prefix of 12345, with no leading 0s, then:

Total keys = 10000000000
Matches = 1234500000 ... 1234599999 = 100000 total matches
Difficulty = 10000000000 / 100000 = 100000, or 1:100000 keys

It's more complex to do this for base-58, but as in the example, the task is to convert a base-58 prefix into ranges of numbers that result in matches.  If you're interested, I will post more about this.

samr7 - could you give me more info on this. Am I right in thinking I need to understand get_prefix_ranges?

[Remember remember the 5th of November]

samr7,
Is it possible for you to comment a little on what the difficulty number represents and how it's calculated. I tried looking thru the code and figuring it out but BN math and probability is definitely not my forte. I ended up being pretty confused.

I'd like to be able to estimate the probability for a prefix pattern in my own code without running vanitygen - if not perfect mathematically then a rough time estimate would work.

Hi BkkCoins,

Difficulty is the number of keys that have to be checked, on average, to find a match.

The simplest way to do this is to have a table of prefix difficulties, and for each character after the beginning of the prefix, multiply by 58.  For this, you'd have something like:

11 = 256
12-1P = 22
1Q = 65
1R-1z = 1353

So, 1Abc = 22 x 58 x 58 = 74008, and 1egg = 1353 x 58 x 58 = 4551492, which are very close to the exact difficulties.  This scheme wouldn't be very accurate for multiple leading 1s, and certain suffixes of 1Q, without special handling of those cases.


The exact, but more complicated way to do this is to follow the formula:

Difficulty = (Total addresses) / (Matching addresses)

The tricky part is figuring out the number of matching addresses.  If your keys were 10-digit base-10 numbers, and you wanted to find everything with a prefix of 12345, with no leading 0s, then:

Total keys = 10000000000
Matches = 1234500000 ... 1234599999 = 100000 total matches
Difficulty = 10000000000 / 100000 = 100000, or 1:100000 keys

It's more complex to do this for base-58, but as in the example, the task is to convert a base-58 prefix into ranges of numbers that result in matches.  If you're interested, I will post more about this.

How did you come up with this algorithm?

[flatfly]

@samr7:

when searching for a vanity pattern, it occured to me that you could match the compressed keys for each generated secret as well. That would double the efficiency/expected ETA of pretty much every query, wouldn't it? Well, perhaps not double, but at least greatly speed it up...

Or am I just saying nonsense again?

[Remember remember the 5th of November]

Are you talking about the vanity miner or vanitygen?

[samr7]

Can't get the ocl version to work...

On nvidia:

Code:

vg_ocl_context_callback error: CL_MEM_OBJECT_ALLOCATION_FAILURE error executing CL_COMMAND_NDRANGE_KERNEL on GeForce GTX 285 (Device 0).

clWaitForEvents(NDRange,0): CL_MEM_OBJECT_ALLOCATION_FAILURE
Device: GeForce GTX 285
Vendor: NVIDIA Corporation (10de)
Driver: 285.62
Profile: FULL_PROFILE
Version: OpenCL 1.0 CUDA
Max compute units: 30
Max workgroup size: 512
Global memory: 1073741824
Max allocation: 268435456

Hi tgbtc,

Try upgrading your NVIDIA driver.  That version looks kinda old.  Your GTX 285 card should work without question though.

on 7970:
(seems it is finding matches, but disregarding due to mismatch?

Code:

CPU hash: 6707a76e848f5e9368c2d9d9ec6d60880df44891
GPU hash: 020b0bda39a9bbb2eeddd194a8be20934835dff6
Found delta: 94027 Start delta: 1

When you get the CPU hash/GPU hash mismatch, it means the OpenCL device is producing incorrect results.  I have not had a chance to test it on an AMD 7XXX series GCN card yet, but others have reported that it works.  Try running it with -V on that card for a little while and see what you get.  Since it's producing incorrect results, the performance numbers may or may not mean anything.

Hmm perhaps my question wasn't very clear. I'm aware of what you said, what I meant to ask is, does it search within the full (2^256) range of possible private keys or a subset of it. I would have checked the source myself but my C/C++ is a little too rusty...

Hi flatfly,

Vanitygen won't systematically search the entire keyspace.  It picks a random spot, checks a few hundred million keys, and moves to another random spot.  I didn't think it was even worth making it systematic given how improbable it is that two instances of vanitygen will ever check the same keys, as long as the random number generator is behaving correctly.

It also uses a different random spot for each thread or OpenCL device that's being used to search.

when searching for a vanity pattern, it occured to me that you could match the compressed keys for each generated secret as well. That would double the efficiency/expected ETA of pretty much every query, wouldn't it? Well, perhaps not double, but at least greatly speed it up...

I still have to read about compressed keys, but you're probably correct about this, yes!

BTW kudos on deep space vagabond!  I love it.

[samr7]

samr7 - could you give me more info on this. Am I right in thinking I need to understand get_prefix_ranges?

Hi nibor,

What are you trying to do?

To give a base-58 example of how to determine difficulty, let's say you want the prefix 1Boat.  The idea is that when you compute the address of a private key, it is almost completely random and unpredictable, and we consider it to have equal probability of being any possible address.  So, for the prefix 1Boat, any addresses in the following range would work:

1Boat11111111111111111111111111111 - 1Boatzzzzzzzzzzzzzzzzzzzzzzzzzzzzz

Not all of these are valid addresses due to the checksum part at the very end, but we'll gloss over that.

All you have to do is figure out how many addresses are in that range, call it (matching addresses), and then compute:

difficulty = (total addresses, 2^192) / (matching addresses)

That's the average number of addresses you'll have to test before finding a match.

It gets a little bit more complicated because above we're only considering 34 character addresses, and it's possible to have shorter addresses with the same prefix, addresses that are 33 characters or shorter.  In fact, to get a prefix beginning with 1R - 1z, it is only possible using a 33 character address, and this is why those prefixes are so difficult.

[BkkCoins]

If anyone is interested I have written a very short Python module wrapper for the vanitygen difficulty calculation. It creates a Python callable function by linking with the vanitygen C source.

I can put it up on my github if there is interest. It's very short but does expose the difficulty calc routine so you can call it from Python and I use it on my Python vanitycoin.com server API as part of estimating the price for vanity requests.

[flatfly]

Hmm perhaps my question wasn't very clear. I'm aware of what you said, what I meant to ask is, does it search within the full (2^256) range of possible private keys or a subset of it. I would have checked the source myself but my C/C++ is a little too rusty...

Hi flatfly,

Vanitygen won't systematically search the entire keyspace.  It picks a random spot, checks a few hundred million keys, and moves to another random spot.  I didn't think it was even worth making it systematic given how improbable it is that two instances of vanitygen will ever check the same keys, as long as the random number generator is behaving correctly.

It also uses a different random spot for each thread or OpenCL device that's being used to search.

when searching for a vanity pattern, it occured to me that you could match the compressed keys for each generated secret as well. That would double the efficiency/expected ETA of pretty much every query, wouldn't it? Well, perhaps not double, but at least greatly speed it up...

I still have to read about compressed keys, but you're probably correct about this, yes!

BTW kudos on deep space vagabond!  I love it.

Thanks for your answers and glad you liked DSV

[nibor]

New site looking for beta testers:
https://bitcoinvanity.appspot.com

Allows the average non-technical user create free, secure (site does not know the private key) vanity addresses.
Currently in Beta, so might take a while to generate addresses but that should speed up soon.
Give it a go and PM me with any issues.

Please do not post replies on this thread - I will open a fresh one in services once out of Beta and with some more power behind it in terms of GPUs.

[crazyates]

I just found this, and I must say, it's awesome! Getting ~30Mkey/s on my 7970 @ 1150/1485.

[fizzisist]

I posted this question in the vanity pool thread, but realized it really belongs here since it's about oclvanityminer.

Yep, just tried out the client for the first time and I see "Value: 0.000022 BTC/MkeyHr," and it picked that over all the other work. What's with the "Hr?"

BTC (per) Mkey (per) Hour

So...
Say you generate 60Mkey/s...

If the BTC/MkeyHr was 0.005, then you'd make (theoretically, its based on luck) 0.005BTC * 60 every hour.

That would just be BTC/hr, and it would be based on your key generation rate. A more sensible value to quote would be just BTC/Mkey. I get the feeling that this is in fact what is shown in the SW, although I haven't looked closely at it yet. On the other hand, there is no reason it couldn't just show BTC/hr in the SW since it knows your keyrate. (Aside: is that the correct term here? Did I just coin that? )

I finally had a chance to look at the source and apparently the units of the "value" shown are simply BTC/Mkey, but multiplied by 3600, or in code:

Code:

wip->value = (reward * 1000000.0 * 3600.0) / difficulty;

This is not BTC/MKeyHr, this is a meaningless number. More correctly, you could say the units are BTC*s/Mkey*hr. I suggest removing the 3600 and just displaying the value as BTC/Mkey. If the number is too small (too many decimals to be easily readable), change it to BTC/Gkey, since most people are calculating at least a Gkey every minute. If you would like to go one step further, you can show BTC/hr as:

Code:

3600 * rate * reward / difficulty

Where rate is the calculated Mkey/s for your hardware (so vg_output_timing() will have to been called already).

[fizzisist]

If anyone is interested I have written a very short Python module wrapper for the vanitygen difficulty calculation. It creates a Python callable function by linking with the vanitygen C source.

I can put it up on my github if there is interest. It's very short but does expose the difficulty calc routine so you can call it from Python and I use it on my Python vanitycoin.com server API as part of estimating the price for vanity requests.

I would love this. Just started trying to figure out how to calculate this, but I'd rather not reinvent the wheel...

[slush]

I tried vanitypool (cool stuff!) and when my miner found a match, miner printed out HTML page to the console ("Thank you for submitting your solution."). Is that HTML dump expected or it is some bug? It definitely looks weird :-).

[crazyates]

I just found this, and I must say, it's awesome! Getting ~30Mkey/s on my 7970 @ 1150/1485.

on 7970:
(seems it is finding matches, but disregarding due to mismatch?

Code:

CPU hash: 6707a76e848f5e9368c2d9d9ec6d60880df44891
GPU hash: 020b0bda39a9bbb2eeddd194a8be20934835dff6
Found delta: 94027 Start delta: 1

When you get the CPU hash/GPU hash mismatch, it means the OpenCL device is producing incorrect results.  I have not had a chance to test it on an AMD 7XXX series GCN card yet, but others have reported that it works.  Try running it with -V on that card for a little while and see what you get.  Since it's producing incorrect results, the performance numbers may or may not mean anything.

Looks like I spoke too soon, cuz I'm actually getting this this error on my 7970, with 12.8 drivers. I tried a few different flag options, but nothing really worked.

[The00Dustin]

This one does not work for me - window opens and closes after like 5 seconds:

Code:

oclvanityminer.exe -u https://vanitypool.appspot.com/ -a mybtcaddressgoeshere

This one works, uses both CPU cores:

Code:

vanitygen.exe something

WinXP SP3, GPU ATi 4670, SDK 2.5, OpenCL 1.1

Any clue?

Try

Code:

oclvanitygen.exe something

to see if the problem has to do with opencl.

[crazyates]

Looks like I spoke too soon, cuz I'm actually getting this this error on my 7970, with 12.8 drivers. I tried a few different flag options, but nothing really worked.

Well I only get 9Mkey/s instead of 30, but the -S option produces valid results.

[BkkCoins]

If anyone is interested I have written a very short Python module wrapper for the vanitygen difficulty calculation. It creates a Python callable function by linking with the vanitygen C source.

I can put it up on my github if there is interest. It's very short but does expose the difficulty calc routine so you can call it from Python and I use it on my Python vanitycoin.com server API as part of estimating the price for vanity requests.

I would love this. Just started trying to figure out how to calculate this, but I'd rather not reinvent the wheel...

I've now created a repo on github for this. I had to rewrite some today due to a hard disk crash last week but hopefully I didn't mess it up. I think it may actually be better this time around but it hasn't been tested as much as my older version.

https://github.com/bkkcoins/vanitycalc

[fizzisist]

If anyone is interested I have written a very short Python module wrapper for the vanitygen difficulty calculation. It creates a Python callable function by linking with the vanitygen C source.

I can put it up on my github if there is interest. It's very short but does expose the difficulty calc routine so you can call it from Python and I use it on my Python vanitycoin.com server API as part of estimating the price for vanity requests.

I would love this. Just started trying to figure out how to calculate this, but I'd rather not reinvent the wheel...

I've now created a repo on github for this. I had to rewrite some today due to a hard disk crash last week but hopefully I didn't mess it up. I think it may actually be better this time around but it hasn't been tested as much as my older version.

https://github.com/bkkcoins/vanitycalc

Yes! Thank you! I tested this out on Debian and it works like a charm.