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

coblee

donator

Activity: 1654

Merit: 1351

Creator of Litecoin. Cryptocurrency enthusiast.

Quote from: jackjack on August 03, 2011, 08:22:44 PM

Quote from: coblee on August 03, 2011, 07:40:26 PM

Sorry if this was already answered. Is there a way to easily verify that a private/public key pair is valid without having to import it?

Specifically, I want to use vanitygen to generating a few savings account address offline and possibly just write those keys down or print them out. I would prefer to not have to connect my computer to the internet to be safe. But I'm worried about a possible bug in the vanitygen code that may cause it to generate invalid keys. So I don't want to generate an address, put in 1000 bitcoins, then 5 years later find out that the corresponding private key doesn't work!

As vanitygen and pywallet "privkey to pubkey" functions weren't programmed by the same person you can use pywallet (getinfo function) to reassure you

I only see am importprivkey command. I assume that takes in a private key. That doesn't really confirm that the private key matches the public key. And I won't be able to be sure unless I send some money to the public key.

Would it be easy for you to add a command to let me validate priv/pub key pair without importing anything? I don't care for importing it into a wallet.dat file.

jackjack

legendary

Activity: 1176

Merit: 1280

May Bitcoin be touched by his Noodly Appendage

Quote from: coblee on August 03, 2011, 07:40:26 PM

Sorry if this was already answered. Is there a way to easily verify that a private/public key pair is valid without having to import it?

Specifically, I want to use vanitygen to generating a few savings account address offline and possibly just write those keys down or print them out. I would prefer to not have to connect my computer to the internet to be safe. But I'm worried about a possible bug in the vanitygen code that may cause it to generate invalid keys. So I don't want to generate an address, put in 1000 bitcoins, then 5 years later find out that the corresponding private key doesn't work!

As vanitygen and pywallet "privkey to pubkey" functions weren't programmed by the same person you can use pywallet (getinfo function) to reassure you

coblee

donator

Activity: 1654

Merit: 1351

Creator of Litecoin. Cryptocurrency enthusiast.

Sorry if this was already answered. Is there a way to easily verify that a private/public key pair is valid without having to import it?

Specifically, I want to use vanitygen to generating a few savings account address offline and possibly just write those keys down or print them out. I would prefer to not have to connect my computer to the internet to be safe. But I'm worried about a possible bug in the vanitygen code that may cause it to generate invalid keys. So I don't want to generate an address, put in 1000 bitcoins, then 5 years later find out that the corresponding private key doesn't work!

dinox

full member

Activity: 126

Merit: 100

Quote from: samr7 on August 03, 2011, 10:33:11 AM

Tell me about the crash!

With a 9400M, the number you got might not be too bad. It probably needs tweaks to work well on smaller laptop GPUs, and I don't have one to test with. I'll guess that it has long, uncomfortable display lag? The work unit autoconfiguration certainly hasn't been tested with your GPU, and you might get performance or responsiveness improvements from command-line tweaks like -w256 or -g512x256 or -b1024. It needs a built-in benchmark, among other things.

Intresting it works on OS X for others, it's probably my MBP which is the problem. I'm throwing 10.7 Lion at it now so let's see if that fixes the problem...

jackjack

legendary

Activity: 1176

Merit: 1280

May Bitcoin be touched by his Noodly Appendage

Quote from: RaTTuS on August 03, 2011, 11:25:45 AM

Quote from: samr7 on August 03, 2011, 10:54:12 AM

Nice!

If the capitalization was intentional (and it looks like it was), that's one of the most complex prefixes that anyone has found to date.

it was, though I'm looking for another one that stands out a bit more ... but I'm fairly happy with that one Cool

I found Jackjack7eYNdGkbgUUrtKBraSWBUV5DJP too Grin

With such speeds I think an address with 8 fixed characters can be found
Maybe more with vanitygen pools Wink

That might interest some people here: I just finished a web interface for pywallet
Download the last version, run ./pywallet --web and go to localhost:8989

RaTTuS

hero member

Activity: 792

Merit: 1000

Bite me

Quote from: samr7 on August 03, 2011, 10:54:12 AM

Nice!

If the capitalization was intentional (and it looks like it was), that's one of the most complex prefixes that anyone has found to date.

it was, though I'm looking for another one that stands out a bit more ... but I'm fairly happy with that one Cool

defxor

hero member

Activity: 530

Merit: 500

Quote from: samr7 on August 03, 2011, 10:33:11 AM

My older C2D 2.0GHz laptop gets 155 Kkey/s with a single thread. Maybe OpenSSL isn't being built with the assembly code enabled?

Interesting. I would be surprised if the Apple default Snow Leopard OpenSSL installation (0.9.8) wasn't optimized though - the Macports version (1.0.0d) was after all slightly faster. I didn't verify the compile flags used though.

Maybe we should just wait for other Mac users to report in :) My system could possibly have other issues.

Quote

Tell me about the crash!

Sure. Not really understanding the different options I tried starting it with a really low value for worksize:

Code:

$ ./oclvanitygen -w2 -d0 1pattern
Difficulty: 15318045009
vg_ocl_context_callback error: [CL_INVALID_COMMAND_QUEUE] : OpenCL Fatal Error : Kernel execute caused an error that invalidated the queue (0x1004103b0). This may be  due to a resource allocation failure at execution time.
vg_ocl_context_callback error: [CL_INVALID_COMMAND_QUEUE] : OpenCL Error : Failed to wait for events! Event 0 in waitlist failed. Invalid command queue

vg_ocl_context_callback error: [CL_INVALID_COMMAND_QUEUE] : OpenCL Error : clEnqueueNDRangeKernel failed: queue (0x1004103b0) has been invalidated.
clEnqueueNDRange(2): CL_INVALID_COMMAND_QUEUE

(followed by the GPU information I posted above)

Quote

With a 9400M, the number you got might not be too bad. It probably needs tweaks to work well on smaller laptop GPUs, and I don't have one to test with. I'll guess that it has long, uncomfortable display lag? The work unit autoconfiguration certainly hasn't been tested with your GPU, and you might get performance or responsiveness improvements from command-line tweaks like -w256 or -g512x256 or -b1024. It needs a built-in benchmark, among other things.

Really bad lag, yes. Just for reference, for anyone who wants to start fine tuning, I ran (very briefly) all your examples above:

-w256 - no obvious difference in speed or responsiveness
-g512x256 - ~15% slower, more responsive
-b1024 - no obvious difference in speed or responsiveness

samr7

full member

Activity: 140

Merit: 430

Firstbits: 1samr7

Quote from: RaTTuS on August 03, 2011, 08:30:44 AM

+1
new Address in my sig Grin

Nice!

If the capitalization was intentional (and it looks like it was), that's one of the most complex prefixes that anyone has found to date.

samr7

full member

Activity: 140

Merit: 430

Firstbits: 1samr7

Quote from: defxor on August 03, 2011, 09:29:56 AM

It makes no difference in speed compared to using the right lib and the wrong header files (I think there was a 20% speedup or so between the 0.9.8 and 1.0.0 libs though) - but since I'm on a laptop I have no opinion on what's good or bad.

Interesting, so it is binary compatible on OS X? Regardless, something still seems off. You have a smokin' fast CPU. My older C2D 2.0GHz laptop gets 155 Kkey/s with a single thread. Maybe OpenSSL isn't being built with the assembly code enabled?

Quote

My MBP is a 2.53GHz C2D with an NVidia GeForce 9400M. This is the output I can get from oclvanitygen by playing around with the parameters and crashing it Wink

Code:

Device: GeForce 9400M
Vendor: NVIDIA
Driver: CLH 1.0
Profile: FULL_PROFILE
Version: OpenCL 1.0 
Max compute units: 2
Max workgroup size: 512
Global memory: 268435456
Max allocation: 134217728

Tell me about the crash!

With a 9400M, the number you got might not be too bad. It probably needs tweaks to work well on smaller laptop GPUs, and I don't have one to test with. I'll guess that it has long, uncomfortable display lag? The work unit autoconfiguration certainly hasn't been tested with your GPU, and you might get performance or responsiveness improvements from command-line tweaks like -w256 or -g512x256 or -b1024. It needs a built-in benchmark, among other things.

RaTTuS

hero member

Activity: 792

Merit: 1000

Bite me

Oh yeah that was using
oclvanitygen
on a Nvidia280 Card running at about 3.7Mh/s [it took about 3 days]

defxor

hero member

Activity: 530

Merit: 500

Quote from: samr7 on August 03, 2011, 09:14:40 AM

First, congrats on getting oclvanitygen to run! What GPU are you using? The key rate is probably a lot slower than it could be, but at least the OpenCL compiler isn't crashing.

Regarding the OpenSSL warning, that check is a compile-time one, so switching out the shared library won't stop the warning. This brings up a potential issue: I thought that between OpenSSL 0.9.8 and 1.0.0, a bunch of changes were made that broke binary compatibility. To the effect that attempting to build against the header files for 0.9.8 and link with a 1.0.0 library would cause problems. While it doesn't seem to be crashing for you, it should run at about twice the speed you report. Anyway, when building from source, you want to use the header files for 1.0.0.

What we really need is a set of pre-built binaries for OS X, with the 3rd party dependencies static-linked.

Yeah I just managed to fix it, posting as a reply to you now instead of yet another edit to my original post Wink

It was indeed me just being rusty at writing makefiles. For those who install a newer version of OpenSSL using Macports the Makefile needs to look like this:

Code:

LIBS=-L/opt/local/lib -lpcre -lcrypto -lm -lpthread
INCL=-I/opt/local/include
CFLAGS=-ggdb -O3 -Wall $(INCL)
OBJS=vanitygen.o oclvanitygen.o pattern.o
PROGS=vanitygen
TESTS=

all: $(PROGS)

vanitygen: vanitygen.o pattern.o
        $(CC) $^ -o $@ $(CFLAGS) $(LIBS)

oclvanitygen: oclvanitygen.o pattern.o
        $(CC) $^ -o $@ $(CFLAGS) $(LIBS) -framework OpenCL

clean:
        rm -f $(OBJS) $(PROGS) $(TESTS)

It makes no difference in speed compared to using the right lib and the wrong header files (I think there was a 20% speedup or so between the 0.9.8 and 1.0.0 libs though) - but since I'm on a laptop I have no opinion on what's good or bad.

My MBP is a 2.53GHz C2D with an NVidia GeForce 9400M. This is the output I can get from oclvanitygen by playing around with the parameters and crashing it Wink

Code:

Device: GeForce 9400M
Vendor: NVIDIA
Driver: CLH 1.0
Profile: FULL_PROFILE
Version: OpenCL 1.0 
Max compute units: 2
Max workgroup size: 512
Global memory: 268435456
Max allocation: 134217728

Agree about pre-built binaries from a trusted source for those who don't want to spend a few hours going from no build environment to a working one Wink

I like doing it since I was a developer many years ago and want to prove to myself that I haven't forgotten everything. In this case it took way too long to figure out I had put the include path flag at the wrong place ...

samr7

full member

Activity: 140

Merit: 430

Firstbits: 1samr7

Quote from: defxor on August 03, 2011, 07:10:29 AM

I did fail building it towards a newer version of OpenSSL (1.0.0d, installed via macports) though, even though I added both a hardcoded lib path and the correct include paths to the Makefile. I guess it's been too many years since I developed anything in C. (Or did I succeed and it's just the version check prompt that gets its knowledge from elsewhere?)

First, congrats on getting oclvanitygen to run! What GPU are you using? The key rate is probably a lot slower than it could be, but at least the OpenCL compiler isn't crashing.

Regarding the OpenSSL warning, that check is a compile-time one, so switching out the shared library won't stop the warning. This brings up a potential issue: I thought that between OpenSSL 0.9.8 and 1.0.0, a bunch of changes were made that broke binary compatibility. To the effect that attempting to build against the header files for 0.9.8 and link with a 1.0.0 library would cause problems. While it doesn't seem to be crashing for you, it should run at about twice the speed you report. Anyway, when building from source, you want to use the header files for 1.0.0.

What we really need is a set of pre-built binaries for OS X, with the 3rd party dependencies static-linked.

RaTTuS

hero member

Activity: 792

Merit: 1000

Bite me

+1
new Address in my sig Grin

defxor

hero member

Activity: 530

Merit: 500

Quote from: samr7 on August 02, 2011, 01:28:59 AM

Edit: Mac OS X platform support and makefile, added by dinox

Seems to work fine - thanks! I built in on my MBP (had to install pcre first) and tried both vanitygen (~100kk/s - 1 thread, ~170kk/s with 2) and oclvanitygen (~140kk/s) although I haven't imported any keys into a wallet and used them for transactions.

I did fail building it towards a newer version of OpenSSL (1.0.0d, installed via macports) though, even though I added both a hardcoded lib path and the correct include paths to the Makefile. I guess it's been too many years since I developed anything in C. (Or did I succeed and it's just the version check prompt that gets its knowledge from elsewhere?)

edit: This.

Code:

$ otool -L vanitygen
vanitygen:
	/usr/lib/libpcre.0.dylib (compatibility version 1.0.0, current version 1.1.0)
	/opt/local/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
$ otool -L oclvanitygen
oclvanitygen:
	/usr/lib/libpcre.0.dylib (compatibility version 1.0.0, current version 1.1.0)
	/opt/local/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
	/System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL (compatibility version 1.0.0, current version 1.0.0)

vs

Code:

$ ./vanitygen
WARNING: Built with OpenSSL 0.9.8l 5 Nov 2009
WARNING: Use OpenSSL 1.0.0d+ for best performance
Vanitygen 0.16 (OpenSSL 0.9.8l 5 Nov 2009)
Usage: ./vanitygen [-vqrikNT] [-t ] [-f |-] [...]

I've also tried

Code:

export DYLD_LIBRARY_PATH=/opt/local/lib/

in the event it was a runtime loading problem but it didn't change anything.

jackjack

legendary

Activity: 1176

Merit: 1280

May Bitcoin be touched by his Noodly Appendage

Just to let you know, the error was on Ubuntu, not Windows

I don't have access to my laptop right now, i'll test asap

Also I made a mini script to compile when make doesn't find cl.h
I didn't make a pull request because it's rather dirty but it might be useful for some
It's useful for me because I can compile without modifying oclvanitygen.c: the script modifies oclvanitygen.c, runs make, then modifies oclvanitygen.c back

samr7

full member

Activity: 140

Merit: 430

Firstbits: 1samr7

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

Quote from: jackjack on August 01, 2011, 08:46:40 PM

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!

jackjack

legendary

Activity: 1176

Merit: 1280

May Bitcoin be touched by his Noodly Appendage

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

dinox

full member

Activity: 126

Merit: 100

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

samr7

full member

Activity: 140

Merit: 430

Firstbits: 1samr7

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.

Quote from: jackjack on July 31, 2011, 12:56:16 PM

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.

Quote from: jackjack on July 31, 2011, 01:55:20 PM

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.

jackjack

legendary

Activity: 1176

Merit: 1280

May Bitcoin be touched by his Noodly Appendage

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

Topic: Vanitygen: Vanity bitcoin address generator/miner [v0.22] - page 181. (Read 1153620 times)