samr7 (OP)
Full Member
Offline
Activity: 140
Merit: 430
Firstbits: 1samr7
|
|
July 13, 2011, 11:40:12 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. 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
|
|
July 13, 2011, 12:13:33 PM |
|
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
Activity: 2058
Merit: 1005
this space intentionally left blank
|
|
July 13, 2011, 12:30:07 PM |
|
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
|
|
July 13, 2011, 01:07:01 PM |
|
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 (OP)
Full Member
Offline
Activity: 140
Merit: 430
Firstbits: 1samr7
|
|
July 13, 2011, 01:12:27 PM |
|
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 ecdhYour Xeon should be faster than my C2D: 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
|
|
July 13, 2011, 01:38:15 PM |
|
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: 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 (OP)
Full Member
Offline
Activity: 140
Merit: 430
Firstbits: 1samr7
|
|
July 13, 2011, 01:51:58 PM |
|
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
|
|
July 13, 2011, 03:32:31 PM |
|
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
Activity: 96
Merit: 10
|
|
July 13, 2011, 04:15:31 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/pywalletWill 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
Activity: 67
Merit: 130
|
|
July 13, 2011, 04:33:21 PM |
|
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
|
|
July 13, 2011, 04:58:51 PM |
|
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
Activity: 67
Merit: 130
|
|
July 13, 2011, 05:08:18 PM Last edit: July 13, 2011, 05:31:20 PM by 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.
I've fixed this issue (removed tx reader), added max_version and got rid of pycrypto. https://github.com/joric/pywallet
|
1JoricCBkW8C5m7QUZMwoRz9rBCM6ZSy96
|
|
|
Shevek
|
|
July 13, 2011, 09:30:18 PM |
|
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/pywalletWOW!! Thanks!
|
Proposals for improving bitcoin are like asses: everybody has one 1SheveKuPHpzpLqSvPSavik9wnC51voBa
|
|
|
dinox
|
|
July 14, 2011, 05:53:02 PM Last edit: July 14, 2011, 06:08:48 PM by dinox |
|
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 (OP)
Full Member
Offline
Activity: 140
Merit: 430
Firstbits: 1samr7
|
|
July 14, 2011, 10:35:44 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
|
|
July 15, 2011, 11:29:23 AM |
|
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
Offline
Activity: 4284
Merit: 8808
|
|
July 15, 2011, 12:37:59 PM |
|
|
|
|
|
pc
|
|
July 15, 2011, 01:26:27 PM |
|
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.
|
|
|
|
dserrano5
Legendary
Offline
Activity: 1974
Merit: 1029
|
|
July 15, 2011, 02:55:44 PM |
|
Oh my goodness, and I thought my 45 vanity addresses were far too many...
|
|
|
|
Yeti
Member
Offline
Activity: 112
Merit: 10
Firstbits: 1yetiax
|
|
July 15, 2011, 04:43:33 PM |
|
This goes way back to the beginning of the month when there was no vanitygen. http://blockexplorer.com/address/1HnNPy6wtM8pG9TpF1dapvuLTPpdHwiYekSomebody had figured this out earlier, activated them in Firstbits with tx of 1 Satoshi each, not released the code and now keeps all the addresses to sell them later (although that remains to be seen if people would buy private keys from somebody). That's why I can't be 1yeti and that's why we can't have nice things!
|
|
|
|
|