Bitcoin Forum
December 03, 2016, 01:46:54 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 [7] 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 ... 155 »
  Print  
Author Topic: Vanitygen: Vanity bitcoin address generator/miner [v0.22]  (Read 808105 times)
pc
Sr. Member
****
Offline Offline

Activity: 253


View Profile
July 13, 2011, 12:27:21 AM
 #121

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 <pcre.h>. Perhaps there's a better way to get it into the build, but it seems to work for me.
1480772814
Hero Member
*
Offline Offline

Posts: 1480772814

View Profile Personal Message (Offline)

Ignore
1480772814
Reply with quote  #2

1480772814
Report to moderator
1480772814
Hero Member
*
Offline Offline

Posts: 1480772814

View Profile Personal Message (Offline)

Ignore
1480772814
Reply with quote  #2

1480772814
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480772814
Hero Member
*
Offline Offline

Posts: 1480772814

View Profile Personal Message (Offline)

Ignore
1480772814
Reply with quote  #2

1480772814
Report to moderator
Shevek
Sr. Member
****
Offline Offline

Activity: 252



View Profile
July 13, 2011, 10:02:41 AM
 #122

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!


Proposals for improving bitcoin are like asses: everybody has one
1SheveKuPHpzpLqSvPSavik9wnC51voBa
samr7
Full Member
***
Offline Offline

Activity: 140

Firstbits: 1samr7


View Profile
July 13, 2011, 11:40:12 AM
 #123

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!
pc
Sr. Member
****
Offline Offline

Activity: 253


View Profile
July 13, 2011, 12:13:33 PM
 #124

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.
2weiX
Legendary
*
Offline Offline

Activity: 1638


View Profile
July 13, 2011, 12:30:07 PM
 #125

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
****
Offline Offline

Activity: 253


View Profile
July 13, 2011, 01:07:01 PM
 #126

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.
samr7
Full Member
***
Offline Offline

Activity: 140

Firstbits: 1samr7


View Profile
July 13, 2011, 01:12:27 PM
 #127

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
****
Offline Offline

Activity: 253


View Profile
July 13, 2011, 01:38:15 PM
 #128

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
***
Offline Offline

Activity: 140

Firstbits: 1samr7


View Profile
July 13, 2011, 01:51:58 PM
 #129

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
****
Offline Offline

Activity: 253


View Profile
July 13, 2011, 03:32:31 PM
 #130

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.
wannaBhacker
Member
**
Offline Offline

Activity: 96


View Profile
July 13, 2011, 04:15:31 PM
 #131

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?
Joric
Member
**
Offline Offline

Activity: 67


View Profile
July 13, 2011, 04:33:21 PM
 #132

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.

1JoricCBkW8C5m7QUZMwoRz9rBCM6ZSy96
Shevek
Sr. Member
****
Offline Offline

Activity: 252



View Profile
July 13, 2011, 04:58:51 PM
 #133

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.

Proposals for improving bitcoin are like asses: everybody has one
1SheveKuPHpzpLqSvPSavik9wnC51voBa
Joric
Member
**
Offline Offline

Activity: 67


View Profile
July 13, 2011, 05:08:18 PM
 #134

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

1JoricCBkW8C5m7QUZMwoRz9rBCM6ZSy96
Shevek
Sr. Member
****
Offline Offline

Activity: 252



View Profile
July 13, 2011, 09:30:18 PM
 #135

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!

Proposals for improving bitcoin are like asses: everybody has one
1SheveKuPHpzpLqSvPSavik9wnC51voBa
dinox
Full Member
***
Offline Offline

Activity: 126


View Profile
July 14, 2011, 05:53:02 PM
 #136

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.

blockchain.info/fb/1dinox - 1Dinox3mFw8yykpAZXFGEKeH4VX1Mzbcxe
Active trader on #bitcoin-otc - See here - Proof that my nick is dinox here
samr7
Full Member
***
Offline Offline

Activity: 140

Firstbits: 1samr7


View Profile
July 14, 2011, 10:35:44 PM
 #137

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
***
Offline Offline

Activity: 126


View Profile
July 15, 2011, 11:29:23 AM
 #138

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.

I haven't got every thing about ECC clear yet, but what I have understood you can do

Public_key = some_int*Priv_key

Then

New_pub_key = Public_key + another_int*another_ec_point
New_priv_key = priv_key + another_int

Now if you set another_int=1 you only have to do one add each iteration, and if there is a match another add to get the private key. This should speed up the calc a lot if my maths is correct.

blockchain.info/fb/1dinox - 1Dinox3mFw8yykpAZXFGEKeH4VX1Mzbcxe
Active trader on #bitcoin-otc - See here - Proof that my nick is dinox here
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2016



View Profile
July 15, 2011, 12:37:59 PM
 #139


It would appear that vanitygen is now the preferred tool of transaction spammers:

http://blockexplorer.com/tx/60d7988fd2bc22ce764f9651b20fc3e7418ab6ab57c7057a16dfedd22e837b11

pc
Sr. Member
****
Offline Offline

Activity: 253


View Profile
July 15, 2011, 01:26:27 PM
 #140

It would appear that vanitygen is now the preferred tool of transaction spammers:

Yeah, between vanitygen and firstbits, there's been quite a bit of trying to get some nice addresses. I've certainly thrown a couple addresses into the chain myself just to get the vanity firstbits address, but nothing quite like that… But at least that transaction has a fee to pay for it, so it could almost be considered the system working just fine.
Pages: « 1 2 3 4 5 6 [7] 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 ... 155 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!