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

samr7

full member

Activity: 140

Merit: 430

Firstbits: 1samr7

Quote from: dinox on July 14, 2011, 12:53:02 PM

I tried to find an example code of how EC multiplication and add works but couldn't find one. I think we should grab some and translate it to a OCL kernel for running this on a GPU instead.

I've been messing around with this. More than 1/3 of the CPU time spent by the current algorithm is in Montgomery multiplication -- to produce each output address, it must do 14 of them. I have an OpenCL kernel that can correctly perform the Montgomery multiplication. Unfortunately, the performance so far isn't very encouraging.

dinox

full member

Activity: 126

Merit: 100

Nice work, getting ~~380KKeys/s~~ 450KKeys/s (with 8 threads) from my sandy MBP. Got 1DinoX and is now trying to get 1dinox (lowercase).

---

I tried to find an example code of how EC multiplication and add works but couldn't find one. I think we should grab some and translate it to a OCL kernel for running this on a GPU instead.

Edit: We do have the SHA-hashing code for "free" from the miners.

Shevek

sr. member

Activity: 252

Merit: 250

Quote from: Joric on July 13, 2011, 12:08:18 PM

Quote from: Shevek on July 13, 2011, 11:58:51 AM

But it does not work with long-term used wallet.dat file. Even if the server is stopped.
When wallet.dat is freshly created, there is no problem.

I've fixed this issue (removed tx reader), added max_version and got rid of pycrypto. https://github.com/joric/pywallet

WOW!! Thanks!

Joric

member

Activity: 67

Merit: 130

Quote from: Shevek on July 13, 2011, 11:58:51 AM

But it does not work with long-term used wallet.dat file. Even if the server is stopped.
When wallet.dat is freshly created, there is no problem.

I've fixed this issue (removed tx reader), added max_version and got rid of pycrypto. https://github.com/joric/pywallet

Shevek

sr. member

Activity: 252

Merit: 250

Quote from: Joric on July 13, 2011, 11:33:21 AM

Quote from: wannaBhacker on July 13, 2011, 11:15:31 AM

Will this work on windows bitcoin client or is this just for linux. I believe the patch is just for linux isn't it for the actual client?

It doesn't matter, pywallet.py works directly with the database. You have to shut down the bitcoin client to import a key.

Thanks for your app Joric.

But it does not work with long-term used wallet.dat file. Even if the server is stopped.

When wallet.dat is freshly created, there is no problem.

Joric

member

Activity: 67

Merit: 130

Quote from: wannaBhacker on July 13, 2011, 11:15:31 AM

Will this work on windows bitcoin client or is this just for linux. I believe the patch is just for linux isn't it for the actual client?

It doesn't matter, pywallet.py works directly with the database. You have to shut down the bitcoin client to import a key.

wannaBhacker

member

Activity: 96

Merit: 10

Quote from: Joric on July 12, 2011, 05:23:43 PM

Just built up a script (pywallet.py 1.0) allowing export/import private keys in shortened format (mostly as a lightweight alternative to showwallet for those who didn't manage to compile the branch). Requires only openssl libs (for elliptic curve cryptography). URL: https://github.com/joric/pywallet

Will this work on windows bitcoin client or is this just for linux. I believe the patch is just for linux isn't it for the actual client?

pc

sr. member

Activity: 253

Merit: 250

Quote from: samr7 on July 13, 2011, 08:51:58 AM

Yep, definitely build/link vanitygen with 1.0.0d.

Perhaps there should be some sort of warning about older versions of OpenSSL.

Yes, linking against 1.0.0d brings me up to 1.3 Mkey/s with 8 threads, and even up to 1.54 Mkey/s with 16 threads.

Thank you so much for your help. Generating vanity addresses is way more fun than it ought to be.

samr7

full member

Activity: 140

Merit: 430

Firstbits: 1samr7

Quote from: pc on July 13, 2011, 08:38:15 AM

Now, I built OpenSSL 1.0.0d (on a different computer) in order to build my version bitcoin that includes importprivkey, but it's not "installed" on the system, and so my build of vanitygen wouldn't be linked to it. Do you think that doing so would help?

Yep, definitely build/link vanitygen with 1.0.0d.

Perhaps there should be some sort of warning about older versions of OpenSSL.

pc

sr. member

Activity: 253

Merit: 250

Quote from: samr7 on July 13, 2011, 08:12:27 AM

I still think you should be able to get a lot better than 1Mkey/s out of that machine. If you have a few minutes, you might confirm that OpenSSL is up to snuff with: openssl speed ecdsa ecdh

Here's what I've got:

Code:

OpenSSL 0.9.8r 8 Feb 2011
built on: Apr 22 2011
options:bn(64,64) md2(int) rc4(ptr,char) des(idx,cisc,16,int) aes(partial) blowfish(ptr2)
compiler: -arch x86_64 -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O3 -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DMD32_REG_T=int -DOPENSSL_NO_IDEA -DOPENSSL_PIC -DOPENSSL_THREADS -DZLIB -mmacosx-version-min=10.6
available timing options: TIMEB USE_TOD HZ=100 [sysconf value]
timing function used: getrusage
                              sign    verify    sign/s verify/s
 160 bit ecdsa (secp160r1)   0.0002s   0.0008s   5322.7   1218.3
 192 bit ecdsa (nistp192)   0.0002s   0.0008s   5457.1   1276.2
 224 bit ecdsa (nistp224)   0.0003s   0.0014s   3430.3    708.6
 256 bit ecdsa (nistp256)   0.0004s   0.0017s   2848.4    603.4
 384 bit ecdsa (nistp384)   0.0008s   0.0039s   1312.2    257.4
 521 bit ecdsa (nistp521)   0.0010s   0.0051s   1042.0    197.7
 163 bit ecdsa (nistk163)   0.0007s   0.0016s   1374.4    624.4
 233 bit ecdsa (nistk233)   0.0014s   0.0023s    724.8    438.8
 283 bit ecdsa (nistk283)   0.0022s   0.0049s    456.1    202.5
 409 bit ecdsa (nistk409)   0.0049s   0.0106s    205.0     94.2
 571 bit ecdsa (nistk571)   0.0106s   0.0228s     94.6     43.9
 163 bit ecdsa (nistb163)   0.0007s   0.0017s   1359.7    582.9
 233 bit ecdsa (nistb233)   0.0014s   0.0024s    709.5    412.3
 283 bit ecdsa (nistb283)   0.0022s   0.0054s    456.0    186.3
 409 bit ecdsa (nistb409)   0.0048s   0.0122s    206.3     81.8
 571 bit ecdsa (nistb571)   0.0107s   0.0258s     93.8     38.8
                              op      op/s
 160 bit ecdh (secp160r1)   0.0007s   1408.1
 192 bit ecdh (nistp192)   0.0006s   1583.8
 224 bit ecdh (nistp224)   0.0012s    826.8
 256 bit ecdh (nistp256)   0.0014s    703.9
 384 bit ecdh (nistp384)   0.0032s    311.7
 521 bit ecdh (nistp521)   0.0042s    239.2
 163 bit ecdh (nistk163)   0.0008s   1285.3
 233 bit ecdh (nistk233)   0.0011s    898.6
 283 bit ecdh (nistk283)   0.0024s    420.8
 409 bit ecdh (nistk409)   0.0055s    181.7
 571 bit ecdh (nistk571)   0.0111s     90.1
 163 bit ecdh (nistb163)   0.0008s   1214.5
 233 bit ecdh (nistb233)   0.0012s    832.7
 283 bit ecdh (nistb283)   0.0027s    377.1
 409 bit ecdh (nistb409)   0.0059s    170.0
 571 bit ecdh (nistb571)   0.0127s     79.0

Now, I built OpenSSL 1.0.0d (on a different computer) in order to build my version bitcoin that includes importprivkey, but it's not "installed" on the system, and so my build of vanitygen wouldn't be linked to it. Do you think that doing so would help?

samr7

full member

Activity: 140

Merit: 430

Firstbits: 1samr7

Quote from: pc on July 13, 2011, 07:13:33 AM

Getting 680–700 KKey/s now (though it threw me off for a second that you changed the units). I also compiled with -march=core2 -mtune=native, though I don't know if they really did anything.

I still think you should be able to get a lot better than 1Mkey/s out of that machine. If you have a few minutes, you might confirm that OpenSSL is up to snuff with: openssl speed ecdsa ecdh

Your Xeon should be faster than my C2D:

Code:

OpenSSL 1.0.0d 8 Feb 2011
built on: Sat Feb 19 14:49:38 PST 2011
options:bn(64,64) rc4(1x,char) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx) 
compiler: x86_64-pc-linux-gnu-gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DWHIRLPOOL_ASM -O2 -march=native -pipe -momit-leaf-frame-pointer -fno-strict-aliasing -Wa,--noexecstack
                              sign    verify    sign/s verify/s
 160 bit ecdsa (secp160r1)   0.0001s   0.0004s   9278.2   2339.1
 192 bit ecdsa (nistp192)   0.0002s   0.0007s   6080.6   1367.8
 224 bit ecdsa (nistp224)   0.0002s   0.0009s   5158.6   1115.7
 256 bit ecdsa (nistp256)   0.0003s   0.0013s   3729.3    799.5
 384 bit ecdsa (nistp384)   0.0006s   0.0029s   1773.5    346.5
 521 bit ecdsa (nistp521)   0.0007s   0.0038s   1389.8    262.9
 163 bit ecdsa (nistk163)   0.0007s   0.0018s   1333.6    562.5
 233 bit ecdsa (nistk233)   0.0015s   0.0027s    673.7    375.3
 283 bit ecdsa (nistk283)   0.0025s   0.0052s    402.3    191.2
 409 bit ecdsa (nistk409)   0.0059s   0.0119s    169.3     84.0
 571 bit ecdsa (nistk571)   0.0127s   0.0254s     78.6     39.3
 163 bit ecdsa (nistb163)   0.0008s   0.0018s   1332.7    551.1
 233 bit ecdsa (nistb233)   0.0015s   0.0025s    662.0    395.0
 283 bit ecdsa (nistb283)   0.0025s   0.0057s    404.0    176.1
 409 bit ecdsa (nistb409)   0.0059s   0.0129s    170.2     77.4
 571 bit ecdsa (nistb571)   0.0127s   0.0286s     78.8     35.0
                              op      op/s
 160 bit ecdh (secp160r1)   0.0004s   2820.3
 192 bit ecdh (nistp192)   0.0006s   1688.7
 224 bit ecdh (nistp224)   0.0007s   1364.3
 256 bit ecdh (nistp256)   0.0010s    960.9
 384 bit ecdh (nistp384)   0.0024s    408.9
 521 bit ecdh (nistp521)   0.0032s    309.9
 163 bit ecdh (nistk163)   0.0008s   1188.1
 233 bit ecdh (nistk233)   0.0012s    855.0
 283 bit ecdh (nistk283)   0.0026s    388.1
 409 bit ecdh (nistk409)   0.0057s    176.0
 571 bit ecdh (nistk571)   0.0125s     79.8
 163 bit ecdh (nistb163)   0.0009s   1120.6
 233 bit ecdh (nistb233)   0.0012s    811.3
 283 bit ecdh (nistb283)   0.0028s    356.2
 409 bit ecdh (nistb409)   0.0063s    157.8
 571 bit ecdh (nistb571)   0.0142s     70.6

pc

sr. member

Activity: 253

Merit: 250

Quote from: 2weiX on July 13, 2011, 07:30:07 AM

lookitme, imanoob.
how, if i have generated such an adress, can i actually USE it, ie add it to my keyring / wallet.dat so i can have ppl send their BTCs there?

There's a patch for Bitcoin, which lets you import the private key. I thought I saw somewhere on the forums someone who was working on a separate (python?) program that directly modified the wallet.dat so you didn't need to recompile Bitcoin, but I can't find it at the moment.

2weiX

legendary

Activity: 2058

Merit: 1005

this space intentionally left blank

lookitme, imanoob.

this is interesting for purposes of business - ie 1USEDCARSxxx or 1PUSSYGALORExxx etc etc.

how, if i have generated such an adress, can i actually USE it, ie add it to my keyring / wallet.dat so i can have ppl send their BTCs there?

thanks in advance!

pc

sr. member

Activity: 253

Merit: 250

Quote from: samr7 on July 13, 2011, 06:40:12 AM

I just posted version 0.12, and cleaned up this little mess.

The new version also implements a minor tweak to how the EC_POINT batches are handled, which improves prefix key search rate by approx. 10% over the previous version. Significant improvements beyond this will be difficult without replacing pieces of the OpenSSL ec_GFp_simple module. Or maybe not, prove me wrong!

Getting 680–700 KKey/s now (though it threw me off for a second that you changed the units). I also compiled with -march=core2 -mtune=native, though I don't know if they really did anything.

Thank you very much again.

samr7

full member

Activity: 140

Merit: 430

Firstbits: 1samr7

Quote from: Shevek on July 13, 2011, 05:02:41 AM

I've tested the code. A "break;" instance should be after "seedfile = optarg;". After this, the program works perfectly!

Touche! Good catch, despite how embarassing it is. Embarrassed

I just posted version 0.12, and cleaned up this little mess.

The new version also implements a minor tweak to how the EC_POINT batches are handled, which improves prefix key search rate by approx. 10% over the previous version. Significant improvements beyond this will be difficult without replacing pieces of the OpenSSL ec_GFp_simple module. Or maybe not, prove me wrong!

Shevek

sr. member

Activity: 252

Merit: 250

Quote from: samr7 on July 12, 2011, 06:39:50 PM

New version 0.11 posted.

Allow the RNG to be seeded from a file, suggested by Shevek
Tweak the synchronization on the pattern list

Thanks for the seed option!

I've tested the code. A "break;" instance should be after "seedfile = optarg;". After this, the program works perfectly!

pc

sr. member

Activity: 253

Merit: 250

Quote from: samr7 on July 12, 2011, 06:39:50 PM

New version 0.11 posted.

Try a single instance of the new version. It should make a lot fewer pthread synchronization calls, and hopefully scale better on your multi-processor machine. However, I'm still stumped on why each thread is getting about 1/2 the expected key rate. You should be able to do >1MK/s on that machine.

Yes, this seems to be scaling much better. 550000–575000 K/s on 8 threads, 320000 or so on 4 threads, 82000 on 1 thread.

Thank you very much.

And for anyone else compiling on a Mac, I have to add "-I/Developer/SDKs/MacOSX10.5.sdk/usr/include/php/ext/pcre/pcrelib/" to the makefile flags for it to find . Perhaps there's a better way to get it into the build, but it seems to work for me.

bmgjet

member

Activity: 98

Merit: 10

V0.10 is big improvement for me.
Went from finding 1 address per day to find 4.
Just using a LE sempron since running vanitygen takes the cpu from 18c idle to 29c full load and power useage went up by 10w.
My desktop's way quicker finds an address every 2-3 hours but dont like running it full speed since temp goes up to 58C and uses 130W more lol.

Still would love to see what its like on a GPU.

samr7

full member

Activity: 140

Merit: 430

Firstbits: 1samr7

New version 0.11 posted.

Allow the RNG to be seeded from a file, suggested by Shevek
Tweak the synchronization on the pattern list

Quote from: pc on July 12, 2011, 04:42:10 PM

Fascinating. Running two instances at four threads each gives me each instance running about 260000–275000 K/s or so, and each taking up a bit under 400% (probably about as much as they can with the other programs I have running here).

Try a single instance of the new version. It should make a lot fewer pthread synchronization calls, and hopefully scale better on your multi-processor machine. However, I'm still stumped on why each thread is getting about 1/2 the expected key rate. You should be able to do >1MK/s on that machine.

bitlotto

hero member

Activity: 672

Merit: 500

BitLotto - best odds + best payouts + cheat-proof

Quote from: Joric on July 12, 2011, 05:23:43 PM

Just built up a script (pywallet.py 1.0) allowing export/import private keys in shortened format (mostly as a lightweight alternative to showwallet for those who didn't manage to compile the branch). Requires only openssl libs (for elliptic curve cryptography). URL: https://github.com/joric/pywallet

COOL! So I'm assuming you run it with Bitcoin closed and force a rescan so it rescans the entire blockchain.

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