Bitcoin Forum
December 04, 2016, 04:34:11 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 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 117 ... 155 »
  Print  
Author Topic: Vanitygen: Vanity bitcoin address generator/miner [v0.22]  (Read 808332 times)
refer_2_me
Full Member
***
Offline Offline

Activity: 213



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

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
1480869251
Hero Member
*
Offline Offline

Posts: 1480869251

View Profile Personal Message (Offline)

Ignore
1480869251
Reply with quote  #2

1480869251
Report to moderator
1480869251
Hero Member
*
Offline Offline

Posts: 1480869251

View Profile Personal Message (Offline)

Ignore
1480869251
Reply with quote  #2

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

Posts: 1480869251

View Profile Personal Message (Offline)

Ignore
1480869251
Reply with quote  #2

1480869251
Report to moderator
1480869251
Hero Member
*
Offline Offline

Posts: 1480869251

View Profile Personal Message (Offline)

Ignore
1480869251
Reply with quote  #2

1480869251
Report to moderator
scintill
Sr. Member
****
Offline Offline

Activity: 448


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

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: 631


www.cryptobetfair.com


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

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

Anyone have advice?
Kelticfox
Hero Member
*****
Offline Offline

Activity: 534


View Profile
June 22, 2013, 10:55:56 AM
 #1324

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

Anyone have advice?

Same problem on a 7850.

Veni, Vidi, Cidere, Prenda In Gen, Interlitum Verlgo Stipes, Dissiptum.
murfshake
Member
**
Offline Offline

Activity: 83


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

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



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

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: 400


in bitcoin we trust


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

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: 1918


https://keybase.io/bitpop


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

You are missing that cases differ in many times more bits

Reputation  |  PGP  |  DigitalOcean  |  OpenVPN 2GB Free  |  TorGuard  |  Ethereum Classic
Bitcoin: 3DSh6AnmvBpDJFUz2mnLirMLmTMcFs9nDm
Bitmessage: BM-2cXN9j8NFT2n1FxDVQ6HQq4D4MZuuaBFyb
laughingbear
Deflationary champion
Hero Member
*****
Offline Offline

Activity: 631


www.cryptobetfair.com


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

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: 532



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

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



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

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: 532



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

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

Activity: 1918


https://keybase.io/bitpop


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

Yeah I only have asics now

Reputation  |  PGP  |  DigitalOcean  |  OpenVPN 2GB Free  |  TorGuard  |  Ethereum Classic
Bitcoin: 3DSh6AnmvBpDJFUz2mnLirMLmTMcFs9nDm
Bitmessage: BM-2cXN9j8NFT2n1FxDVQ6HQq4D4MZuuaBFyb
laughingbear
Deflationary champion
Hero Member
*****
Offline Offline

Activity: 631


www.cryptobetfair.com


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

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

Activity: 448


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

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: 532



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

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: 631


www.cryptobetfair.com


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

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

Activity: 700



View Profile
June 28, 2013, 05:11:52 PM
 #1338

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.

Very different process.

adam3us
Sr. Member
****
expert
Offline Offline

Activity: 400


in bitcoin we trust


View Profile WWW
June 28, 2013, 05:45:08 PM
 #1339

anyone know how I might go about disabling BFI_INT?

If you can change source and recompile, try commenting out these two lines.


Thats what I figured and already tried: doesnt work (on amd 7870, catalyst 13.4, fedora 18.)

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.

I tried that one and it has the same CPU hash GPU hash not matching issue (with or without BFI_INT disabled).

This kind of sucks.  Must be some more bugs lurking or catalyst driver bugs?

btw I am finding vanity addresses aiming for with lower case are much harder to compute seemingly, 1 out of 58 I generated so far with vanitygen -i are lower first char.  I think there maybe a target range miscalculation in vanitygen that is discarding valid finds?  Clearly all start strings are possible because 1zzz finds lots and so does 1111.  The alphabet is [1-0][A-Z][a-z] and strings before 1QQQ are easier.  Except 1111 is harder.  I am not really understanding why this is.  OpenSSL doco says it uses big endian encoding.  And the base58 encoder seems to use the same convention, so you would expect restrictions on the most significant digit.  However that doesnt seem to be the case empirically.

The address is encoded as 0x1 || hash(160-bits) || checksum(32-bits) which is 193-bits.  Now log(58,2^193) = 32.9465 and 2^193/58^32 = 46.676 however the bignum is encoded big endian

Adam

hashcash, committed transactions, homomorphic values, blind kdf; researching decentralization, scalability and fungibility/anonymity
adam3us
Sr. Member
****
expert
Offline Offline

Activity: 400


in bitcoin we trust


View Profile WWW
June 28, 2013, 07:44:38 PM
 #1340

btw I am finding vanity addresses aiming for with lower case are much harder to compute seemingly, 1 out of 58 I generated so far with vanitygen -i are lower first char.  I think there maybe a target range miscalculation in vanitygen that is discarding valid finds?  Clearly all start strings are possible because 1zzz finds lots and so does 1111.  The alphabet is [1-0][A-Z][a-z] and strings before 1QQQ are easier.  Except 1111 is harder.  I am not really understanding why this is.  OpenSSL doco says it uses big endian encoding.  And the base58 encoder seems to use the same convention, so you would expect restrictions on the most significant digit.  However that doesnt seem to be the case empirically.

Playing with this some more I think it is the case that 1 is special (it is the encoding for digit 0), and then values after first digit P (in the base58 alphabet) are possible; values after that are not directly possible however become possible when you get a short key (leading 0) as leading 0s are suppressed.  So all lowercase values and values starting Q only are at least one character short.

That means you're going to have a lot more fun if you start with upper case first char, below Q.

Adam

hashcash, committed transactions, homomorphic values, blind kdf; researching decentralization, scalability and fungibility/anonymity
Pages: « 1 ... 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 117 ... 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!