Bitcoin Forum
June 13, 2024, 05:13:09 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 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 58 59 60 61 62 63 64 65 [66] 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 ... 191 »
  Print  
Author Topic: Vanitygen: Vanity bitcoin address generator/miner [v0.22]  (Read 1152891 times)
OZR
Sr. Member
****
Offline Offline

Activity: 281
Merit: 250

You're in my wonderland!


View Profile
June 21, 2013, 01:49:33 PM
 #1301

How to generate an address similar to the 1ABC**************************ABC ?

* - A random simbol
refer_2_me
Full Member
***
Offline Offline

Activity: 213
Merit: 100



View Profile
June 21, 2013, 02:13:22 PM
 #1302

How to generate an address similar to the 1ABC**************************ABC ?

* - A random simbol

There may be a better way, but you could run vanity gen with just the prefix:
Code:
vanitygen -k -o matches.txt 1ABC

To generate a bunch of addresses that start with 1ABC, then grep to find ones that end with it:
Code:
grep 'ABC$' matches.txt
The '$' looks for matches at the end of a line.

BTC: 1reFerkRnftob5YvbB112bbuwepC9XYLj
XPM: APQpPZCfEz3kejrYTfyACY1J9HrjnRf34Y
nimda
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1000


0xFB0D8D1534241423


View Profile
June 21, 2013, 02:32:30 PM
 #1303

How to generate an address similar to the 1ABC**************************ABC ?

* - A random simbol

There may be a better way, but you could run vanity gen with just the prefix:
Code:
vanitygen -k -o matches.txt 1ABC

To generate a bunch of addresses that start with 1ABC, then grep to find ones that end with it:
Code:
grep 'ABC$' matches.txt
The '$' looks for matches at the end of a line.
^ This way will be faster, but vanitygen supports regex directly with the -r parameter.
refer_2_me
Full Member
***
Offline Offline

Activity: 213
Merit: 100



View Profile
June 21, 2013, 02:41:33 PM
Last edit: June 21, 2013, 05:52:21 PM by refer_2_me
 #1304

OK, I switched it to use OpenSSL for the key derivation, and it is much faster.  Did a 99,171 word dictionary file in 53 seconds: 1,871 per second (3 GHz processor.)  The downside could be that it doesn't work on your system because it's not pure Python.  I think it's supposed to work on Windows if you have OpenSSL DLL's, and maybe on Mac OS too.  It's here: https://gist.github.com/scintill/5829284/54bcc0a9a44809c3fb4b53259239316520bbfe17 .  The OpenSSL wrapper is from here: https://github.com/joric/brutus/blob/master/ecdsa_ssl.py .

Make sure you are using the right compression flag (which translates into the DER-encoding of the pubkey: starts with 04 hex byte if uncompressed, 02 or 03 if compressed.)  Whether your address is compressed will depend on what tool and settings you used to generate it.  If it has been spent from before, then you can look in the blockchain to be sure of whether it is compressed or not.  Otherwise, I don't think you can tell from just the address.  You can tell from the private key, which starts with 5 if uncompressed, K or L if compressed.

The Python way can be parallelized pretty easily by splitting the input file into, say, 4 files, and running 4 instances of the script at a time.

If you want to try OpenCL, from what little I know, I think it would be best to do the SHA256 in batches (so the inputs are the same smallish uniform size they are now), then give all the hashes to the OpenCL kernel, and have each kernel derive the hash160 and see if it equals the target address, and run those in parallel.  I guess the SHA256 becomes a bottleneck, so maybe it would be better to try to do that in the OpenCL kernel, but as far as memory management it might be harder to adjust the vanitygen design for string inputs.

Also, I think the base58-encode is not quite right in the Python. It should pad with "1" for each leading zero in the public key hash.  If your target address doesn't start with "11..." I don't think it will matter though.

Oh man, I can't thank you enough. I can confirm that it works on my installation of Ubuntu 13.04 BTW. I haven't recovered the key yet, but it won't take long now.

Thanks again!


So I'm actually having some troubles. It worked fine with a short list (~2000) passphrases that I tried. But I ran it on a longer list of passphrases (modifications of mine) and it ran for a bit then segfaulted. I tried it again and the same thing. I tried it on a list of random 2 word pass phrases, and it ran through a lot of them then seg faulted. Rerunning it, it segfaults on around the same place about 12,000-12,100 guesses in each time. Any idea what could be going wrong?

And what details about my setup would you need to diagnose it?

Edit: it mostly seems to be crashing at:
Code:
pub_key = ssl.EC_POINT_new(group)

Edit 2: The segfault does not seem to be dependent on the actual passphrase being checked. Pulling out the one that made it crashed into a separate file and then running it runs fine. I think that there may be a memory leak in the ecdsa_ssl.py script, but I'm not sure where.

Edit 3: So after realizing that something (couldn't figure out what) had eaten up 47/48GB of memory, I rebooted (I know, classic) and it seems to be running fine.

BTC: 1reFerkRnftob5YvbB112bbuwepC9XYLj
XPM: APQpPZCfEz3kejrYTfyACY1J9HrjnRf34Y
refer_2_me
Full Member
***
Offline Offline

Activity: 213
Merit: 100



View Profile
June 21, 2013, 02:49:25 PM
 #1305

How to generate an address similar to the 1ABC**************************ABC ?

* - A random simbol

There may be a better way, but you could run vanity gen with just the prefix:
Code:
vanitygen -k -o matches.txt 1ABC

To generate a bunch of addresses that start with 1ABC, then grep to find ones that end with it:
Code:
grep 'ABC$' matches.txt
The '$' looks for matches at the end of a line.
^ This way will be faster, but vanitygen supports regex directly with the -r parameter.
Ah, i missed that parameter.
You may be right about speed, I'm not sure.
But to answer OZR's question, what you want to do is:
Code:
vanitygen -r '^1ABC.*ABC$'

BTC: 1reFerkRnftob5YvbB112bbuwepC9XYLj
XPM: APQpPZCfEz3kejrYTfyACY1J9HrjnRf34Y
scintill
Sr. Member
****
Offline Offline

Activity: 448
Merit: 254


View Profile WWW
June 21, 2013, 10:05:07 PM
 #1306

Edit 3: So after realizing that something (couldn't figure out what) had eaten up 47/48GB of memory, I rebooted (I know, classic) and it seems to be running fine.

Ouch, glad you got it sorted.  It could be leaking memory.  I do see some free() calls, so the author put some consideration into it, but they may have missed others.  Generating tens of thousands of keys in one run isn't a usecase they probably considered.  I don't know much about ctypes to know for sure.  Good luck!

1SCiN5kqkAbxxwesKMsH9GvyWnWP5YK2W | donations
laughingbear
Deflationary champion
Hero Member
*****
Offline Offline

Activity: 622
Merit: 500


www.cryptobetfair.com


View Profile WWW
June 21, 2013, 10:43:20 PM
 #1307

Still looking to fix this endless loop bug with the 7970.  It crashes when I try to use safemode.

Anyone have advice?
murfshake
Member
**
Offline Offline

Activity: 84
Merit: 10


View Profile
June 22, 2013, 07:21:40 PM
 #1308

Still looking to fix this endless loop bug with the 7970.  It crashes when I try to use safemode.

Anyone have advice?

Same thing on my 7970.  Damn,
refer_2_me
Full Member
***
Offline Offline

Activity: 213
Merit: 100



View Profile
June 24, 2013, 12:26:25 AM
 #1309

Edit 3: So after realizing that something (couldn't figure out what) had eaten up 47/48GB of memory, I rebooted (I know, classic) and it seems to be running fine.

Ouch, glad you got it sorted.  It could be leaking memory.  I do see some free() calls, so the author put some consideration into it, but they may have missed others.  Generating tens of thousands of keys in one run isn't a usecase they probably considered.  I don't know much about ctypes to know for sure.  Good luck!

So I am still running into some issues where it segfaults. Does anyone have any suggestions for things I can do to debug what the problem is? I'm pretty good with python, but I haven't used ctypes before, and I have only a passing familiarity with C.

BTC: 1reFerkRnftob5YvbB112bbuwepC9XYLj
XPM: APQpPZCfEz3kejrYTfyACY1J9HrjnRf34Y
adam3us
Sr. Member
****
expert
Offline Offline

Activity: 404
Merit: 360


in bitcoin we trust


View Profile WWW
June 27, 2013, 11:27:32 AM
 #1310

Also seeing the CPU hash / GPU hash error message on AMD 7870.

Running with -V has the same problem but slower.  -S crashes.  This on fedora.

I notice there was news of a recent open source update from AMD, not sure if that made it to the package managers yet, but maybe someone wants to try see if that fixes.

Its unclear to me if its an oclvanity bug or an AMD driver bug.  However people in the thread seem to be experiencing the same problem on windows.

Has anyone had any success contacting samr7?  I tried to contact him with a bug report for something else related to vanitygen, and I have to say it strikes me a bit suspicious that a bitcoin related tool that is generating private keys has an uncontactable author and maintainer.  Even email to samr7@cs.washington.edu bounces with no such user, again suspicious.  (Maybe he finished his course, but he has a bitcointalk account also that he doesnt answer).  My bug so far was just about the probably incorrectness of timing estimates based on time to compute strings with and without capitalization. 

eg 7 chars projects 3888 times longer case sensitive vs case insensitive.  Thats seems likely incorrect as the work to find a string that is case insensitive is 2x less for each alphabetic character.  So a 7 char target should be 2^7 = 128x faster not 3888x faster.  Thats out by a factor of 30.  Am I missing anything?

(I mean excluding the leading 1 ie 1abcdefg: vanitygen 1abcdefg vs vanitygen -i 1abcdefg.)

Adam

Edit 3: So after realizing that something (couldn't figure out what) had eaten up 47/48GB of memory, I rebooted (I know, classic) and it seems to be running fine.

Ouch, glad you got it sorted.  It could be leaking memory.  I do see some free() calls, so the author put some consideration into it, but they may have missed others.  Generating tens of thousands of keys in one run isn't a usecase they probably considered.  I don't know much about ctypes to know for sure.  Good luck!

So I am still running into some issues where it segfaults. Does anyone have any suggestions for things I can do to debug what the problem is? I'm pretty good with python, but I haven't used ctypes before, and I have only a passing familiarity with C.

hashcash, committed transactions, homomorphic values, blind kdf; researching decentralization, scalability and fungibility/anonymity
bitpop
Legendary
*
Offline Offline

Activity: 2912
Merit: 1060



View Profile WWW
June 27, 2013, 02:07:06 PM
 #1311

You are missing that cases differ in many times more bits

laughingbear
Deflationary champion
Hero Member
*****
Offline Offline

Activity: 622
Merit: 500


www.cryptobetfair.com


View Profile WWW
June 27, 2013, 02:10:48 PM
 #1312

THis guy claims to have it working on a 7970, by disabling BFI_INT.

https://bitcointalk.org/index.php?topic=57410.msg695201#msg695201
Quote
linux, cat 11.12, sdk2.6, vanitygen git, disabled BFI_INT to get correct results
925/1375 28.1Mk/s
1125/1375 32.4Mk/s
1125/1575 33.2Mk/s
1170/1600 34.1Mk/s

some more testing, disabled EXPENSIVE_BRANCHES and DEEP_VLIW, -g 2048x2048 -b 256
925/1375 37.1Mk/s
1125/1375 43.0Mk/s
1125/1575 43.7Mk/s
1170/1600 45.0Mk/s

more tweaking...
925/1375 39.8Mk/s
1125/1375 46.6Mk/s
1170/1600 49.1Mk/s

edit: 50.1Mk/s at 1200/1600



How do I disable BFI_INT ?

FlappySocks
Hero Member
*****
Offline Offline

Activity: 546
Merit: 500



View Profile
June 27, 2013, 08:35:00 PM
 #1313

I wonder now hard it would be to get cgminer to generate vanity addresses?  Seems logical it could use the hashing power of your miners to do it.
refer_2_me
Full Member
***
Offline Offline

Activity: 213
Merit: 100



View Profile
June 27, 2013, 08:51:04 PM
 #1314

Why bother, just use vanitygen or oclvanitygen (for GPU). The tool is already written, has a bunch of nice features and it is fast.

BTC: 1reFerkRnftob5YvbB112bbuwepC9XYLj
XPM: APQpPZCfEz3kejrYTfyACY1J9HrjnRf34Y
FlappySocks
Hero Member
*****
Offline Offline

Activity: 546
Merit: 500



View Profile
June 27, 2013, 08:53:40 PM
 #1315

Seems to be a lot of problems with it, and it hasn't kept up with FPGAs and ASICs
bitpop
Legendary
*
Offline Offline

Activity: 2912
Merit: 1060



View Profile WWW
June 28, 2013, 01:42:28 AM
 #1316

Yeah I only have asics now

laughingbear
Deflationary champion
Hero Member
*****
Offline Offline

Activity: 622
Merit: 500


www.cryptobetfair.com


View Profile WWW
June 28, 2013, 01:52:23 AM
 #1317

anyone know how I might go about disabling BFI_INT?
scintill
Sr. Member
****
Offline Offline

Activity: 448
Merit: 254


View Profile WWW
June 28, 2013, 06:56:10 AM
 #1318

anyone know how I might go about disabling BFI_INT?

If you can change source and recompile, try commenting out these two lines.  If you're handy with a hex editor, try searching for the string "cl_amd_media_ops" in your binary and overwriting with X's or some unique string, which should permanently disable BFI_INT (though I wonder if the .exe/ELF/whatever has some checksums that will throw an error when you run the program.)

Seems to be a lot of problems with it, and it hasn't kept up with FPGAs and ASICs

Well, I'm 99% sure no existing Bitcoin-mining ASIC can be repurposed for vanity mining.  FPGAs, maybe, but it requires more skill than GPU programming, so there just aren't that many capable of doing it, and even fewer that would do it for free.

I have to say it strikes me a bit suspicious that a bitcoin related tool that is generating private keys has an uncontactable author and maintainer.

It is interesting.  It looks like the private keys are generated by OpenSSL though, so it should be pretty safe.  For your GPU issue, you might also try disabling the BFI_INT optimization as I mentioned above.

It might be nice to "appoint" a new maintainer of vanitygen, or at least collect all the different patches and get some new builds.  For example, this fork appears to have some build/compatibility improvements, and salfter and I have added compressed address support.

1SCiN5kqkAbxxwesKMsH9GvyWnWP5YK2W | donations
FlappySocks
Hero Member
*****
Offline Offline

Activity: 546
Merit: 500



View Profile
June 28, 2013, 11:38:34 AM
 #1319

Well, I'm 99% sure no existing Bitcoin-mining ASIC can be repurposed for vanity mining.  FPGAs, maybe, but it requires more skill than GPU programming, so there just aren't that many capable of doing it, and even fewer that would do it for free.

I assumed vanity mining used the same computational process, only doing something different with the output.
laughingbear
Deflationary champion
Hero Member
*****
Offline Offline

Activity: 622
Merit: 500


www.cryptobetfair.com


View Profile WWW
June 28, 2013, 03:08:13 PM
 #1320

If you can change source and recompile, try commenting out these two lines.  If you're handy with a hex editor, try searching for the string "cl_amd_media_ops" in your binary and overwriting with X's or some unique string, which should permanently disable BFI_INT (though I wonder if the .exe/ELF/whatever has some checksums that will throw an error when you run the program.)

I tried with the hex editor, and you guessed correctly, it threw an error.   I think this may be beyond me.
Pages: « 1 ... 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 58 59 60 61 62 63 64 65 [66] 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 ... 191 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!