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

[jackjack]

Having Generated an address I want how do I get it in the client?

Use this tool: https://github.com/jackjack-jj/pywallet

Nice fork! I love the feature --importhex. But --info does not work. :-(

I also like the clean way EC-mathematics are presented. Perhaps I'll use them for my own purposes.

It works, but reads the keys with --importprivkey, --info is just a non-argument flag
I know it's not practical, i'll change that and put some examples in the README too

[1713912084]

1713912084

[1713912084]

1713912084

[1713912084]

1713912084

[1713912084]

1713912084

[1713912084]

1713912084

[1713912084]

1713912084

[HostFat]

Can someone upload the oclvanitygen win32 bin somewhere?

[winnetou]

great tool, tried it in my vm and got a lot of sex addresses, my favorite: 15mWHVWtR4fX66VTg1Ytn1dCB1RpX8pimp is there also a macintosh binary available?

[dinox]

great tool, tried it in my vm and got a lot of sex addresses, my favorite: 15mWHVWtR4fX66VTg1Ytn1dCB1RpX8pimp is there also a macintosh binary available?

We are working on that.

I changed to a compiler called clc and it compiled calc_addr.cl with no errors/warnings.

That's good, but what changed?  Did you pull the git changes from Thursday 7/21 and try again, or is this with the same calc_addrs.cl that caused the segv last time?
Well, I'm stumped.  According to Apple's developer site, GLD is the modular OpenGL driver interface.  However, Google doesn't seem to know _anything_ about a "gld context creation failed" message.

What version of OS X is this?  Can you pastebin the output of clinfo?  Are you able to run any other OpenCL software on this machine, besides just the clc compiler?  Can you post a link to this compiler?

If you really think the third parameter is causing the problem, it would be a good experiment to change it to CL_QUEUE_PROFILING_ENABLE or even CL_QUEUE_OUT_OF_ORDER_EXEC_MODE_ENABLE.

Nothing changed, I use the same old version as last time. poclbm miner works fine using opencl. I'll try downloading newest version and the clinfo thingy tomorrow.

Btw, should I push the changes I've done for compiling it on osx for review?

[jackjack]

I think I found an error in the code: when vanitygen writes the base58 private key, it always uses 0 as address version instead of addrtype value

Ok I just read the code, it obviously use privtype which is always 0 (even for namecoin) except for testnet where it is 239
I really don't understand why, I think it's just making a mess
Moreover, pywallet (both) doesn't understand and see the address as a bitcoin one

[enmaku]

Can someone upload the oclvanitygen win32 bin somewhere?

+1, wish it were as easy as Linux' gcc for win32

[samr7]

Can someone upload the oclvanitygen win32 bin somewhere?

There's no release of oclvanitygen yet, just what's in git, and that's only half baked right now.  If this doesn't bother you, I posted a binary here.  Also, please let me know if it works or not, I don't have a windows system with a GPU to test it on, and AMD's OpenCL CPU compiler blows up on the kernel.

Edit: The link was updated, the first zip file was missing the OpenCL kernel.

Btw, should I push the changes I've done for compiling it on osx for review?

Please do!!

I think I found an error in the code: when vanitygen writes the base58 private key, it always uses 0 as address version instead of addrtype value

Can you give more details on this?

If it were using 0 as the address version, then wouldn't the encoded private key start with a 1?  It should typically produce private keys starting with '5' for regular bitcoin and namecoin addresses, and '9' for testnet addresses.

[jackjack]

I think I found an error in the code: when vanitygen writes the base58 private key, it always uses 0 as address version instead of addrtype value

Can you give more details on this?

If it were using 0 as the address version, then wouldn't the encoded private key start with a 1?  It should typically produce private keys starting with '5' for regular bitcoin and namecoin addresses, and '9' for testnet addresses.

Thanks to you I just figured out something important (privtype=addrtype+128)
But anyway, isn't it supposed to be '7' for namecoin addresses? My main problem was that: I couldn't import namecoin keys, pywallet saw them as bitcoin ones

Yeah, after more tests I'm nearly sure that you use 128 instead of 128+52 for namecoin privkeys versions
I look at the code and tell you what I find


Edit: Found

Code:

		case 'N':
			addrtype = 52;
			break;

'privtype = 180;' is missing

[samr7]

Thanks to you I just figured out something important (privtype=addrtype+128)
But anyway, isn't it supposed to be '7' for namecoin addresses? My main problem was that: I couldn't import namecoin keys, pywallet saw them as bitcoin ones

Yeah, after more tests I'm nearly sure that you use 128 instead of 128+52 for namecoin privkeys versions
I look at the code and tell you what I find


Edit: Found

Code:

		case 'N':
			addrtype = 52;
			break;

'privtype = 180;' is missing

At this point, I think your pywallet code is the only way to get private keys into or out of a namecoin wallet, so you get to set the conventions, and I will update vanitygen to follow this rule.

[jackjack]

I just sent a pull request before viewing your post
As it used to be 239 for testnet and 128 for bitcoin (mentionned in february) I thought it was rather accepted by all
Moreover Joric did use chr(addrtype+128) to get privkeys

[Sukrim]

Would be neat to have pywallet (or some similar functionality) somehow integrated in this --> specify a wallet file at launch and get the vanity key(s) directly inserted (or after some yes/no confirmation).

After all, this is one of the most common use cases I guess...

[jackjack]

Edited: nvm

[Sukrim]

It imports adresses found by vanitygen on the fly in a wallet.dat? At least I don't see anything about that in the thread there...

Maybe pywallet could at least take the output file of vanitygen as input for easier import?

[jackjack]

Oh sorry I'd better wake up correctly before posting...
Well, for now nothing does that, but I can look into that

[jackjack]

I got it working! With some playing on makefile though

5.7 16.3 (with last version) Mkey/s on a Sapphire 5850

[jackjack]

I found an error (which was not here before I believe):
When I use the case-insensitive flag, Namecoin addresses are seen beginning with a 'n', which is not possible with the 52 addrtype
Then this is what I got:

Code:

Prefix 'n1d' not possible
Hint: valid namecoin addresses begin with "M" or "N"

I tried to modify that in your code, but didn't find where to change that

[samr7]

I posted a couple of new versions of vanitygen.  Summary of changes:

• [0.14] Add jackjack's fix for namecoin private keys
• [0.14] First release of oclvanitygen
• [0.15] Include the OpenCL kernel in the zip file
• [0.15] Warn when using NVIDIA driver on Windows other than known-working version

The oclvanitygen kernel code seems to trigger problems in a number of OpenCL driver stacks.  Certain NVIDIA drivers on Windows and Linux seem to produce invalid PTX code, to the point that commenting out some number of lines in one of the kernels fixes the problem (but the commented lines are required for correct results).  It also seems to cause AMD's KernelAnalyzer to crash, and AMD's CPU OpenCL compiler is unable to build a binary without crashing, either from oclvanitygen itself, or any of the standalone OpenCL compiler programs.

I got it working! With some playing on makefile though

5.7 16.3 (with last version) Mkey/s on a Sapphire 5850

I'm glad you got it to work!

That's about the expected key rate with the latest version on a high end Radeon card.

NVIDIA cards aren't quite as fast, my GTX 285 produces about 6.3 Mkey/s.

I found an error (which was not here before I believe):
When I use the case-insensitive flag, Namecoin addresses are seen beginning with a 'n', which is not possible with the 52 addrtype
Then this is what I got:

Code:

Prefix 'n1d' not possible
Hint: valid namecoin addresses begin with "M" or "N"

I tried to modify that in your code, but didn't find where to change that

Nice find.  I'll see about fixing this.

[dinox]

Made a pull request for reviewing, please dont pull it yet since compiling no longer works on osx. I'm not so good in C but do you have an idea of what's causing the problem samr7? See error output here

[jackjack]

I just saw the -o flag, I will make pywallet read the output files

On my laptop oclvanitygen crashes (actually it worked once and crashes since then):

Code:

Difficulty: 4553521
clBuildProgram: CL_BUILD_PROGRAM_FAILURE
Build log:
Internal error: Link failed.
Make sure the system setup is correct.
Device: ATI RV730
Vendor: Advanced Micro Devices, Inc.
Driver: CAL 1.4.1385
Profile: FULL_PROFILE
Version: OpenCL 1.0 ATI-Stream-v2.1 (145)
Max compute units: 8
Max workgroup size: 128
Global memory: 268435456
Max allocation: 268435456

I made a commit adding the addrtype flag and sent it
I used it to make the address of both Namecoin Faucet and Testnet Namecoin Faucet: FaucetFbyx6bCZX84Va8YxAxUNMxJfJhRD

[samr7]

Version 0.16 has been posted.  Changes include:

• New -X flag to specify numeric key version number, added by jackjack
• oclvanitygen performance tweaks for Radeon cards
• New safe mode flag (-S) for oclvanitygen to disable loop unrolling
• Fix for cached kernel binaries not being loaded correctly on Windows, as reported by jackjack
• Edit: Mac OS X platform support and makefile, added by dinox

Code:

clBuildProgram: CL_BUILD_PROGRAM_FAILURE
Build log:
Internal error: Link failed.
Make sure the system setup is correct.

This should be fixed, please let me know if it's not.  And thanks for the patches!