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

[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.

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.

Here's the full output; it doesn't seem to do any calculation before segfaulting:

Code:

$ ./oclvanitygen -d0 -v -i 1test
Prefix difficulty:             17606948 1test
Difficulty: 17606948
Device: GeForce GT 120
Vendor: NVIDIA (1022600)
Driver: CLH 1.0
Profile: FULL_PROFILE
Version: OpenCL 1.0 
Max compute units: 4294967300
Max workgroup size: 512
Global memory: 536870912
Max allocation: 134217728
OpenCL compiler flags: -DDEEP_PREPROC_UNROLL 
Loading kernel binary 2883e067f0d6d3d9b75e3f670239ca65.oclbin
Grid size: 1024x1024
Modular inverse: 2048 threads, 512 ops each
Using OpenCL prefix matcher
vg_ocl_context_callback error: [CL_OUT_OF_RESOURCES] : OpenCL Error : Failed to wait for events! Event 0 in waitlist failed. Out of resources

vg_ocl_context_callback error: [CL_OUT_OF_RESOURCES] : OpenCL Error : Failed to wait for events! Event 0 in waitlist failed. Out of resources

vg_ocl_context_callback error: [CL_INVALID_KERNEL] : OpenCL Error : Failed to wait for events! Event 0 in waitlist failed. Invalid kernel object

vg_ocl_context_callback error: [CL_INVALID_KERNEL] : OpenCL Error : Failed to wait for events! Event 0 in waitlist failed. Invalid kernel object

vg_ocl_context_callback error: [CL_INVALID_KERNEL] : OpenCL Error : Failed to wait for events! Event 0 in waitlist failed. Invalid kernel object

vg_ocl_context_callback error: [CL_INVALID_KERNEL] : OpenCL Error : Failed to wait for events! Event 0 in waitlist failed. Invalid kernel object

vg_ocl_context_callback error: [CL_INVALID_KERNEL] : OpenCL Error : Failed to wait for events! Event 0 in waitlist failed. Invalid kernel object

vg_ocl_context_callback error: [CL_INVALID_COMMAND_QUEUE] : OpenCL Fatal Error : Finish caused an error that invalidated the queue (0x10ab10620). This may be  due to a resource allocation failure at execution time.
vg_ocl_context_callback error: [CL_INVALID_COMMAND_QUEUE] : OpenCL Error : clCommandDispatch failed: flushing queue for blocking call.
vg_ocl_context_callback error: [CL_INVALID_COMMAND_QUEUE] : OpenCL Error : clEnqueueMapBuffer failed: Invalid command queue
clEnqueueMapBuffer(0): CL_INVALID_COMMAND_QUEUE
Segmentation fault

Though if your "back of the napkin" calculations are right, I get the same rate (600 Kkey/s) from using 16 threads on the two quad-core 2.26 GHz Xeons I've got in this Mac, so probably a moot point to get it working on the GPU.

As I mentioned, I have gotten GPU miners running on this machine, and they pull around 5 Megahashes/second. Is the address generation that much more complex that it gets one-tenth the speed (600 KKey/s ~= 0.6 MKey/s)?

[unclemantis]

Can we add the method for generating public addresses starting with the number 3 as well as 1?

[samr7]

Here's the full output; it doesn't seem to do any calculation before segfaulting:

Code:

...

Though if your "back of the napkin" calculations are right, I get the same rate (600 Kkey/s) from using 16 threads on the two quad-core 2.26 GHz Xeons I've got in this Mac, so probably a moot point to get it working on the GPU.

As I mentioned, I have gotten GPU miners running on this machine, and they pull around 5 Megahashes/second. Is the address generation that much more complex that it gets one-tenth the speed (600 KKey/s ~= 0.6 MKey/s)?

Hi midnightlightning,

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

Try the following command line:

Code:

./oclvanitygen -d0 -v -b 128 -g 256x256 -i 1test

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.

Can we add the method for generating public addresses starting with the number 3 as well as 1?

Hi unclemantis,

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

Code:

$ ./vanitygen -F script 3Love
Difficulty: 4553521
Pattern: 3Love                                                                 
P2SHAddress: 3Love2U8TrDhNZvdvNa5akVcizP2jNi7t5
Address: 1LFUpSr7qTXjtvJowCnD19tu8tBVKUXaRe
Privkey: 5JE2zrTLBUXNi8Rz7QVjNRj4r45Ghvqc7w2nVJHf1sHCVW9Qiw8

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:

Code:

addmultisigaddress 1 [\"1LFUpSr7qTXjtvJowCnD19tu8tBVKUXaRe\"]

(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.

[TYDIRocks]

I created a quick little app in .Net to import private keys without having to enter console commands since the current bitcoin-qt version doesn't have a debug window. Is anyone interested or should I just keep this to myself? :p

[BkkCoins]

I created a quick little app in .Net to import private keys without having to enter console commands since the current bitcoin-qt version doesn't have a debug window. Is anyone interested or should I just keep this to myself? :p

If it is easy to use then many people would love that. See this thread over here,

https://bitcointalk.org/index.php?topic=92080.0

Someone wanting an easy way to import private keys. You might want to create your own thread explaining how to use it and then direct him to yours to try it. You should probably do something to give confidence it's not a trojan as otherwise people should be leary.

[TYDIRocks]

I created a quick little app in .Net to import private keys without having to enter console commands since the current bitcoin-qt version doesn't have a debug window. Is anyone interested or should I just keep this to myself? :p

If it is easy to use then many people would love that. See this thread over here,

https://bitcointalk.org/index.php?topic=92080.0

Someone wanting an easy way to import private keys. You might want to create your own thread explaining how to use it and then direct him to yours to try it. You should probably do something to give confidence it's not a trojan as otherwise people should be leary.

Thanks, do you think this section is the appropriate place to post it?

[BkkCoins]

Thanks, do you think this section is the appropriate place to post it?

Probably, I guess. If not then it may get moved. You may want to start in the general discussion board as it's probably not very technical and of more general user interest. And if the mods don't like it there they'll move it here. But more people will notice it there. Either way we shouldn't continue in this thread.

[TYDIRocks]

Yup I have released the program here: https://bitcointalk.org/index.php?topic=101161.0 (no means of hijacking your thread samr7)

[unclemantis]

Here's the full output; it doesn't seem to do any calculation before segfaulting:

Code:

...

Though if your "back of the napkin" calculations are right, I get the same rate (600 Kkey/s) from using 16 threads on the two quad-core 2.26 GHz Xeons I've got in this Mac, so probably a moot point to get it working on the GPU.

As I mentioned, I have gotten GPU miners running on this machine, and they pull around 5 Megahashes/second. Is the address generation that much more complex that it gets one-tenth the speed (600 KKey/s ~= 0.6 MKey/s)?

Hi midnightlightning,

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

Try the following command line:

Code:

./oclvanitygen -d0 -v -b 128 -g 256x256 -i 1test

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.

Can we add the method for generating public addresses starting with the number 3 as well as 1?

Hi unclemantis,

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

Code:

$ ./vanitygen -F script 3Love
Difficulty: 4553521
Pattern: 3Love                                                                 
P2SHAddress: 3Love2U8TrDhNZvdvNa5akVcizP2jNi7t5
Address: 1LFUpSr7qTXjtvJowCnD19tu8tBVKUXaRe
Privkey: 5JE2zrTLBUXNi8Rz7QVjNRj4r45Ghvqc7w2nVJHf1sHCVW9Qiw8

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:

Code:

addmultisigaddress 1 [\"1LFUpSr7qTXjtvJowCnD19tu8tBVKUXaRe\"]

(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.

This doesn't work for vanitygen-0.19-win

[midnightlightning]

Try the following command line:

Code:

./oclvanitygen -d0 -v -b 128 -g 256x256 -i 1test

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.

Grids of 256x256, 128x128, and 32x32 all segfault in the same way as the original:

Code:

$ ./oclvanitygen -d0 -v -b 128 -g 32x32 -i 1test
Prefix difficulty:             17606948 1test
Difficulty: 17606948
Device: GeForce GT 120
Vendor: NVIDIA (1022600)
Driver: CLH 1.0
Profile: FULL_PROFILE
Version: OpenCL 1.0 
Max compute units: 4294967300
Max workgroup size: 512
Global memory: 536870912
Max allocation: 134217728
OpenCL compiler flags: -DDEEP_PREPROC_UNROLL 
Loading kernel binary 2883e067f0d6d3d9b75e3f670239ca65.oclbin
Grid size: 32x32
Modular inverse: 8 threads, 128 ops each
Using OpenCL prefix matcher
vg_ocl_context_callback error: [CL_OUT_OF_RESOURCES] : OpenCL Error : Failed to wait for events! Event 0 in waitlist failed. Out of resources

vg_ocl_context_callback error: [CL_INVALID_KERNEL] : OpenCL Error : Failed to wait for events! Event 0 in waitlist failed. Invalid kernel object

vg_ocl_context_callback error: [CL_INVALID_KERNEL] : OpenCL Error : Failed to wait for events! Event 0 in waitlist failed. Invalid kernel object

vg_ocl_context_callback error: [CL_INVALID_COMMAND_QUEUE] : OpenCL Fatal Error : Finish caused an error that invalidated the queue (0x10041d070). This may be  due to a resource allocation failure at execution time.
vg_ocl_context_callback error: [CL_INVALID_COMMAND_QUEUE] : OpenCL Error : clCommandDispatch failed: flushing queue for blocking call.
vg_ocl_context_callback error: [CL_INVALID_COMMAND_QUEUE] : OpenCL Error : clEnqueueMapBuffer failed: Invalid command queue
clEnqueueMapBuffer(0): CL_INVALID_COMMAND_QUEUE
Segmentation fault

[unclemantis]

Try the following command line:

Code:

./oclvanitygen -d0 -v -b 128 -g 256x256 -i 1test

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.

Grids of 256x256, 128x128, and 32x32 all segfault in the same way as the original:

Code:

$ ./oclvanitygen -d0 -v -b 128 -g 32x32 -i 1test
Prefix difficulty:             17606948 1test
Difficulty: 17606948
Device: GeForce GT 120
Vendor: NVIDIA (1022600)
Driver: CLH 1.0
Profile: FULL_PROFILE
Version: OpenCL 1.0 
Max compute units: 4294967300
Max workgroup size: 512
Global memory: 536870912
Max allocation: 134217728
OpenCL compiler flags: -DDEEP_PREPROC_UNROLL 
Loading kernel binary 2883e067f0d6d3d9b75e3f670239ca65.oclbin
Grid size: 32x32
Modular inverse: 8 threads, 128 ops each
Using OpenCL prefix matcher
vg_ocl_context_callback error: [CL_OUT_OF_RESOURCES] : OpenCL Error : Failed to wait for events! Event 0 in waitlist failed. Out of resources

vg_ocl_context_callback error: [CL_INVALID_KERNEL] : OpenCL Error : Failed to wait for events! Event 0 in waitlist failed. Invalid kernel object

vg_ocl_context_callback error: [CL_INVALID_KERNEL] : OpenCL Error : Failed to wait for events! Event 0 in waitlist failed. Invalid kernel object

vg_ocl_context_callback error: [CL_INVALID_COMMAND_QUEUE] : OpenCL Fatal Error : Finish caused an error that invalidated the queue (0x10041d070). This may be  due to a resource allocation failure at execution time.
vg_ocl_context_callback error: [CL_INVALID_COMMAND_QUEUE] : OpenCL Error : clCommandDispatch failed: flushing queue for blocking call.
vg_ocl_context_callback error: [CL_INVALID_COMMAND_QUEUE] : OpenCL Error : clEnqueueMapBuffer failed: Invalid command queue
clEnqueueMapBuffer(0): CL_INVALID_COMMAND_QUEUE
Segmentation fault

It crashes on a DLL.

Perhaps I will try the LINUX version Thank you for the help!

[samr7]

Grids of 256x256, 128x128, and 32x32 all segfault in the same way as the original:

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).

Code:

./oclvanitygen -d0 -v -S -b 128 -g 256x256 -i 1test

This doesn't work for vanitygen-0.19-win

It crashes on a DLL.

Perhaps I will try the LINUX version Thank you for the help!

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

[samr7]

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:
  

Code:

$ ./oclvanitygen -D 0:0 -D 0:1 -D 0:2 1MuLtiGPU

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.

[doca]

Testing version 0.20 on CPU Xeon E5603 @1.60GHz with 2x GPU Nvidia Quadro NVS 295 .

Running on first GPU oclvanitygen.exe -v -D 0:0 1doca

Code:

oclvanitygen.exe -v -D 0:0 1doca
Prefix difficulty:            264104224 1doca
Difficulty: 264104224
Device: Quadro NVS 295
Vendor: NVIDIA Corporation (10de)
Driver: 301.32
Profile: FULL_PROFILE
Version: OpenCL 1.0 CUDA
Max compute units: 1
Max workgroup size: 512
Global memory: 268435456
Max allocation: 134217728
OpenCL compiler flags: -DPRAGMA_UNROLL -cl-nv-verbose
Loading kernel binary 326dd0c36930c6bea7602a3270b8186c.oclbin
Grid size: 1024x512
Modular inverse: 512 threads, 1024 ops each
Using OpenCL prefix matcher
GPU idle: 14.39%
[136.18 Kkey/s][total 130023424][Prob 38.9%][50% in 6.5min]

Running on second GPU (must be the one connected to display)

Code:

oclvanitygen.exe -v -D 0:1 1doca
Prefix difficulty:            264104224 1doca
Difficulty: 264104224
Device: Quadro NVS 295
Vendor: NVIDIA Corporation (10de)
Driver: 301.32
Profile: FULL_PROFILE
Version: OpenCL 1.0 CUDA
Max compute units: 1
Max workgroup size: 512
Global memory: 268435456
Max allocation: 134217728
OpenCL compiler flags: -DPRAGMA_UNROLL -cl-nv-verbose
Loading kernel binary 326dd0c36930c6bea7602a3270b8186c.oclbin
Grid size: 1024x512
Modular inverse: 512 threads, 1024 ops each
Using OpenCL prefix matcher
GPU idle: 13.61%
[115.99 Kkey/s][total 2097152][Prob 0.8%][50% in 26.0min]                      c
lEnqueueUnmapMemObject(4): CL_INVALID_COMMAND_QUEUE
clEnqueueMapBuffer(0): CL_INVALID_COMMAND_QUEUE
clWaitForEvents(NDRange,0): CL_OUT_OF_RESOURCES
vg_ocl_context_callback error: CL_OUT_OF_RESOURCES error waiting for idle on Quadro NVS 295 (Device 0).
vg_ocl_context_callback error: CL_INVALID_COMMAND_QUEUE error executing CL_COMMAND_UNMAP_MEM_OBJECT on Quadro NVS 295 (Device 0).
vg_ocl_context_callback error: CL_OUT_OF_RESOURCES error waiting for idle on Quadro NVS 295 (Device 0).
vg_ocl_context_callback error: CL_OUT_OF_RESOURCES error waiting for idle on Quadro NVS 295 (Device 0).
vg_ocl_context_callback error: CL_OUT_OF_RESOURCES error waiting for idle on Quadro NVS 295 (Device 0).
vg_ocl_context_callback error: CL_OUT_OF_RESOURCES error waiting for idle on Quadro NVS 295 (Device 0).
vg_ocl_context_callback error: CL_OUT_OF_RESOURCES error waiting for idle on Quadro NVS 295 (Device 0).
vg_ocl_context_callback error: CL_OUT_OF_RESOURCES error waiting for idle on Quadro NVS 295 (Device 0).
vg_ocl_context_callback error: CL_OUT_OF_RESOURCES error waiting for idle on Quadro NVS 295 (Device 0).

Running on CPU vanitygen64

Code:

vanitygen64.exe -v 1doca
Prefix difficulty:            264104224 1doca
Difficulty: 264104224
Using 4 worker thread(s)
[431.31 Kkey/s][total 5718272][Prob 2.1%][50% in 6.9min]

Running on CPU vanitygen

Code:

vanitygen.exe -v 1doca
Prefix difficulty:            264104224 1doca
Difficulty: 264104224
Using 4 worker thread(s)
[291.27 Kkey/s][total 7392256][Prob 2.8%][50% in 10.1min]

I was not expecting that Quadro NVS 295 would be so slow: 130 Kkeys/s on GPU vs. 430 Kkeys/s on CPU.

Any ideas why I got that crash on second GPU?

[samr7]

Testing version 0.20 on CPU Xeon E5603 @1.60GHz with 2x GPU Nvidia Quadro NVS 295 .

Running on first GPU oclvanitygen.exe -v -D 0:0 1doca

Code:

...

Running on second GPU (must be the one connected to display)

Code:

...

Running on CPU vanitygen64

Code:

vanitygen64.exe -v 1doca
Prefix difficulty:            264104224 1doca
Difficulty: 264104224
Using 4 worker thread(s)
[431.31 Kkey/s][total 5718272][Prob 2.1%][50% in 6.9min]

Running on CPU vanitygen

Code:

vanitygen.exe -v 1doca
Prefix difficulty:            264104224 1doca
Difficulty: 264104224
Using 4 worker thread(s)
[291.27 Kkey/s][total 7392256][Prob 2.8%][50% in 10.1min]

I was not expecting that Quadro NVS 295 would be so slow: 130 Kkeys/s on GPU vs. 430 Kkeys/s on CPU.

Any ideas why I got that crash on second GPU?

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:

Code:

oclvanitygen -v -D 0:1,grid=128x128,invsize=512 1doca

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.

[BkkCoins]

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.

[samr7]

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.

[BkkCoins]

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.

Thank you. This is exactly what I need. Simple, if not 100% accurate. Difficulty is what I thought but wasn't sure about. Are those numbers good to use or just examples? My intention is to come up with a rough time estimate based on current MKeys/s. It doesn't matter if it's out somewhat as I will fudge the result with a safety factor based on past results (and any single run is random anyway).

Thx again. I expect to send a donation your way if my project works out.

[axus]

I try to use MinGW to compile on my Windows box, I had a little trouble compiling vanitygen here.  I got it working after including winglue.o in the objects and pasting code into winglue.c:

http://fossies.org/dox/R-2.15.1/glpi_8h_source.html

[doca]

Hi samr7!

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

I wish I have a Metastock with BTC trade feed! No, just 2 cards, no monitors at all.

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:

Code:

oclvanitygen -v -D 0:1,grid=128x128,invsize=512 1doca

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.

Thanks! Very interesting!

Now second card runs smooth! Thanks!

Code:

oclvanitygen -D 0:1,grid=128x128,invsize=512 1doca
Difficulty: 264104224
[94.62 Kkey/s][total 2621440][Prob 1.0%][50% in 31.8min]

Two card running same time:

Code:

oclvanitygen -D 0:0 -D 0:1,grid=128x128,invsize=512 1doca
Difficulty: 264104224
[229.34 Kkey/s][total 16072704][Prob 5.9%][50% in 12.1min]

Gee! I have so much fun!