Hi fizzisist,

You're right, it's an entirely arbitrary and not 100% correctly labelled unit.  I just wanted it to display some semi-comparable notion of value.  The idea was to create something along the lines of kilowatt-hours, whereas the proper unit would be megajoules, but the power company doesn't publish their electricity rates per megajoule.

Anyway, I'll take your patch on GitHub to convert the display unit to GKeys.  Thanks!

Hi wigglyuk,

Do you use an HTTP proxy?

Oclvanitygen uses libcurl, and unfortunately it won't read your proxy settings for MSIE or Firefox.  If you need to set a proxy, you can set the http_proxy or HTTPS_PROXY environment variables.  For example:

There have been a lot of questions lately about additive vs. multiplicative, and how they work in oclvanitygen/oclvanityminer.  I'll try to answer them.

Oclvanityminer uses the additive method:

• Generate a random partial private key
• Calculate the associated partial public key
• Add the base public key to the partial public key to get the test public key
• Generate a large batch (~1M) of sequential addresses by successively adding the generator point to the test public key, and converting the points to addresses
• If a match is found, report the partial private key plus the number of times the test public key was incremented.  Otherwise, repeat the previous step

Sequential public keys in this scheme are generated by successively adding the generator point to the test public key.  In the multiplicative method, we would skip adding the base public key to the test key at the start, and use the base public key as the increment instead of the generator point.

If anyone really wants to use the multiplicative method instead, it's possible to modify oclvanityminer to do this by changing maybe 5-10 lines of code.  The performance difference would be negligible.

You are correct that oclvanityminer will search for addresses belonging to a single public key at a time.  I'm not sure how additive vs. multiplicative makes a difference in the ability to concurrently search for patterns using different base public keys.  For that matter, I'm not quite sure how to efficiently search for multiple patterns with different base public keys in the first place.

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.

Hi tgbtc,

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


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.


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.


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.

All these bounties have exposed a few bugs in oclvanityminer.  There were a handful of issues with the bounty list parser, and those have been fixed in git.  Another issue that also came up, the solve URL for vanity pool doesn't appear to accept POST requests.  It sends me back an error when I post something.  I changed oclvanityminer to use GET instead of POST for submitting solutions, and it seems to work.  I will post new binaries soon.

Edit: Pick up vanitygen 0.22

Is this the open-source driver?  How well does it work with other OpenCL applications?

I've never used it before, and am amazed that it appears to be advanced enough to support OpenCL.

Edit: According to the Gallium3D wiki, OpenCL on R800/Radeon 5xxx is "WIP".  Still amazing though.

What hardware/OS/drivers are you guys using?

When oclvanitygen does this, it means:

• The OpenCL code reported having found a matching address
• The address was re-calculated using the CPU
• The address calculated by the CPU did not match what was calculated by the GPU, or any patterns in the pattern list

Unfortunately, I have a small variety of hardware to test with, and don't have a platform that can reproduce this type of problem with current code.

Some folks in the past have reported this type of problem using AMD hardware with Catalyst drivers.  Some of them had reported that the problem went away after upgrading to Catalyst 11.11.  Certain older versions of NVIDIA drivers will cause failures too, but tend to cause oclvanitygen to crash, rather than hash mismatches like we're seeing here.

One way to detect this type of problem quickly is to use OpenCL verification mode (-V).  This causes oclvanitygen to run the normal address generation procedure, but to verify results at every step of the way.  It runs much slower, but if there is misbehavior on the OpenCL side, it will find it quickly, and will isolate the kernel that is producing incorrect results.


Interesting, was this with AMD hardware?  Do you remember which driver you were using on Linux?

Ideas looking forward

It's possible to make vanity address mining much like regular bitcoin mining, in the sense of tracking the total work completed by each participant, and possibly distributing rewards to all participants rather than just the finder.  The idea would be, if somebody wants 1DanieLRH, post the bounty for 1Danie, and keep track of how many addresses each miner returns.  Eventually, a matching address will come back, and all of the partial matches will make it possible to determine the division of compute resources.

It also wouldn't hurt if the pool posted the portion of the bounty that will go to whoever solves it, rather than the amount paid by the customer.  It's a letdown to see a bounty for 0.1 BTC, and only receive 0.08 on completion.

It does rank bounties by reward/difficulty.  Choosing the 8 letter prefix is the best choice here, but not by much:


It will also group together bounties by public key.  When the 1Satoshi and 1satoshi bounties were both present, because they had the same public key, they would go into the same pattern set and would be searched for simultaneously.  Also, when dealing with bounties with the same public key, the aggregate reward/difficulty is used for decision making.  This would cause it to choose those two bounties together over the 1DaneiLRH bounty, if it were present.

Anyway, expect a new release in the next day or so that has an oclvanityminer64.exe.


You mean for the -a parameter?  It should accept a testnet address there.  Did it not accept one for you?  It is supposed to validate that what you enter for the -a parameter is a valid address of some sort, but it won't enforce a specific address type.


That's the right address.

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.

Hi doca,

Quadro NVS huh?  You must have a fancy multi-monitor stock broker setup.

The performance you're getting from the GPU isn't too far off from what one might expect.  According to the Wikipedia article, the Quadro NVS 295 is based on G98 and has 8 CUDA cores with shader clock @ 1300 MHz.

The simple formula for NVIDIA G90/GT200 devices is:

Key/s = (CUDA cores) x (Shader clock MHz) x 17

For the NVS 295, it's 177 Kkey/s, which means oclvanitygen is probably underperforming, and would benefit from tweaking.

The failure is probably because oclvanitygen is trying to allocate too much GPU memory.  Try the following on your active GPU:


To tweak performance, change the invsize value to some larger or smaller power of two.  As long as the grid is large enough, there is a sweet spot for this parameter that will provide the best performance, and oclvanitygen might not be smart enough to choose it automatically.

Yes, please!  It should meet all the requirements.  One minor exception though, it looks like you specifically want 64-bit Windows binaries, but I only build the OpenCL pieces for 32-bit Windows.  This can be changed.


Indeed, determining a "difficulty" for a PCRE style regular expression is quite the can of worms.

It should be possible to design a subset of PCRE that can be converted directly into a bunch of prefixes, instead of having to execute the regular expression on each potentially matching address.  The idea would be to force the RE to start with a ^, disallow *, limit the length, and limit the resulting number of prefixes.  This would be a lot more expressive than a case-sensitive or case-insensitive prefix, and just as fast to search.  It would also solve the problem of executing REs on the GPU, as long as the RE isn't so complicated that it creates a search table that is too large to fit on the GPU.

One feature you may wish to consider adding to vanity pool, the ability to specify case-insensitivity in bounties.

Whoever posted the bounties for 1Satoshi and 1satoshi paid for two different addresses differing only in the case of the first letter.  It's entirely possible that that person simply wants that name on firstbits, and would rather pay for one case-insensitive address.  Also, at the reward offered for those bounties, finding a case-insensitive match would be very close to profitable, but finding either of the case-sensitive variants is not.

Or maybe not in this case, looks like 1satoshi is taken on firstbits.

The vanitygen suite now includes a program called oclvanityminer that is designed to work with this pool.  Please try it out!


I'm happy to throw what meager compute power I have at this.  However, the bounties for the above example would have to be about 10X what they are to be as lucrative as bitcoin mining at the current difficulty.

Version 0.20 has been released.  Improvements include:

• Oclvanitygen and oclvanityminer are now able to control multiple GPUs.
  This makes it simpler to manage oclvanitygen on systems with multiple GPUs.  To do this, you must use the new -D command line option, once for each GPU, and must specify the OpenCL platform ID and device ID for each GPU.  Example, for a mining system with three GPUs:
  

On a system with multiple GPUs, running oclvanitygen 1 or otherwise not specifying a device will cause it to display a list of OpenCL devices.  This list can be used to find the platform/device IDs.

• Multiple pattern input files supported
  It's now possible to search for case-sensitive and case-insensitive prefixes concurrently.  Put each type in a separate file, and do something like:
  
  Code:

  $ ./vanitygen -f casesensitive.txt -i -f caseinsensitive.txt
• Bug fixes
  Crash in vanitygen with -X option (thanks forum user foo)
  Case-insensitive search for prefixes containing I, O, and l should work now (thanks deepceleron)
  Oclvanitygen should now display the address correctly with -X option
  Oclvanityminer can now follow HTTP redirections
  
• Oclvanityminer is now able to group together bounties by public key.
  This will be important in the future, when vanity pool gets more attention.  Bounties with the same public key are now processed concurrently, just like specifying multiple prefixes to oclvanitygen.  The economics of this are also taken into account when choosing a bounty or set of bounties.

So that didn't work, but at least now we can feel confident that it's not simply trying to allocate too much global memory.  Yet something certainly seems to be broken with resource allocation and clEnqueueMapBuffer().

I made some improvements to the error handling code in the git repository.  Please pull and try again.  It shouldn't segfault any more, and should give a more useful message at the end.

There are two other boilerplate things you can try: Safe mode (-S) and OpenCL verification mode (-V).




Interesting, which DLL does it complain about?  Did you ever get it to work on Windows?

Hi midnightlightning,

I see, so it's not even getting started.

Try the following command line:


If it works, try increasing the grid size, maybe -g 512x512 or -g 512x1024, but stick to powers of two.  If it doesn't work, try an even smaller grid, maybe -g 128x128.  To tweak the performance, try different modular inverse batch sizes, maybe -b 64 or -b 32.  Also stick to powers of two for that value.

Oclvanitygen will try to automatically determine the best values for those parameters.  It's a hack right now that has only been tested extensively on large discrete GPUs with lots of dedicated memory.  It would make sense for it to get them wrong, and the whole mechanism might need to be re-examined.



Hi unclemantis,

This feature is implemented, but it's limited right now.  Here's a usage example:


You can go ahead and import this private key, but you'll only get the 1LFUpSr7qTXjtvJowCnD19tu8tBVKUXaRe address in your address book, not the one that starts with the 3.  The next step is to select Help -> Debug Window, select the Console tab, and enter the following command:


(Yes, enter it verbatim including the backslashes)

Then you'll get the 3- address in your address book and can receive coins on it.

Make sense?

Currently oclvanitygen can't search for script addresses.  Also, in the future it may become possible to generate script addresses substantially faster by using embedded nonces, to the point that one can find 3- addresses with a few more characters of prefix than 1- addresses.

Hi midnightlightning,

Sorry to hear it's having issues on your Mac.

How long did it run before you got this error message?  Did it make any progress?

Try running it with -v to get verbose output.

Unfortunately, I do not have any Apple hardware to test with, let alone do performance tuning.  Also, as near as I can tell, Apple has their own OpenCL stack that differs substantially from what one might find in the Catalyst or nVidia drivers on Windows/Linux.  So, you've hit kind of a sore spot right now.


I think you're right about it in this case.  A back-of-the-napkin calculation suggests that a GeForce GT 120M @ 500Mhz with 32 CUDA cores should be capable of an upper bound of 650 Kkey/s.

However, for the record, primary development work on the vanitygen OpenCL kernel has been done using a high-end nVidia card.  It runs a lot faster on AMD hardware, but the nVidia platform doesn't receive any less attention for that reason.

Interesting idea.  So, by ordering in bulk, you mean post multiple bounties with the same public key?  Then the mining client can run them all at the same time, and when deciding which bounties to go after, it should sum the cost-reward of all bounties with the same public key.