Bitcoin Forum
January 20, 2018, 05:35:08 AM *
News: Latest stable version of Bitcoin Core: 0.15.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 ... 173 »
  Print  
Author Topic: Vanitygen: Vanity bitcoin address generator/miner [v0.22]  (Read 1104877 times)
Kelticfox
Hero Member
*****
Offline Offline

Activity: 535


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

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.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1516426508
Hero Member
*
Offline Offline

Posts: 1516426508

View Profile Personal Message (Offline)

Ignore
1516426508
Reply with quote  #2

1516426508
Report to moderator
1516426508
Hero Member
*
Offline Offline

Posts: 1516426508

View Profile Personal Message (Offline)

Ignore
1516426508
Reply with quote  #2

1516426508
Report to moderator
murfshake
Member
**
Offline Offline

Activity: 85


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

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
 #1323

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
 #1324

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


https://keybase.io/bitpop


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

You are missing that cases differ in many times more bits

Reputation  |  PGP  |  DigitalOcean  |  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
 #1326

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



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

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
 #1328

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



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

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

Activity: 2212


https://keybase.io/bitpop


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

Yeah I only have asics now

Reputation  |  PGP  |  DigitalOcean  |  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
 #1331

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
 #1332

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



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

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
 #1334

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
 #1335

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
 #1336

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
 #1337

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

Activity: 1512



View Profile WWW
June 28, 2013, 07:46:57 PM
 #1338

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

The change happens at a particular address

This is a result of how the 25-byte (50 digit hexadecimal) underlying hashes are converted into Base58 (represented by numbers and letters) addresses, and the different maximum values that can be stored in 25 base256 digits vs 34 base58 digits.

The Bitcoin address in it's native binary form (that you never see) is 25 bytes, it's parts are:
byte 0: Network ID Byte (0x00 for main bitcoin network)
byte 1-20: ripemd160 hash (20 bytes) of sha256 hash (32 bytes) of 0x04+public key (65 bytes)
byte 21-24: checksum: first four bytes of sha256 hash of sha256 hash of bytes 0-20 above

This would be 50 hexadecimal characters long (base16), with a possible digit value between 0-F - 24 bytes or 48 hexadecimal digits of random hash output, plus the beginning "00" byte.

We will ignore byte 0, it is always 0x00, and Base58 conversion always preserves this leading 0 byte by directly encoding it as a "1".

That means the "vanity" part of the address is generated by the first several bytes of the underlying ripemd160 hash

The minimum this can be is 0000000000000000000000000000000000000000 00000000.
The maximum value that this can be is FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF ffff ffff
(the extra 0s and lower case "f"s are the checksum part.)

Here are some sample addresses before and after the "wraparound" of the maximum hash value.


See how the 1QLa addresses are full length, but the 1QLc addresses are one digit shorter? That is because the only way to have an address starting at 1QLc or greater is by having a binary address that is 59x smaller. There are 59x less possible hashes that will generate a 33 character 1aaaa address than will generate a 34 character 1AAAA address.
scintill
Sr. Member
****
Offline Offline

Activity: 448


View Profile WWW
June 28, 2013, 08:04:55 PM
 #1339

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

Hmm.  I've just realized the -S flag, which you said you already tried, includes disabling BFI_INT.  Can you run the OpenCL code on your CPU (-d, -D, or -p flags, see --help)?  Feedback from that might help narrow down the problem to an OpenCL compiler issue or hardware difference.

I tried with the hex editor, and you guessed correctly, it threw an error.   I think this may be beyond me.

What was the error?  I've since tried this on both Windows and Linux and the resulting binary seemed to work (don't know that it disabled BFI_INT.)  Are you sure you overwrote (instead of inserting) and didn't change anything else?

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

Activity: 631


www.cryptobetfair.com


View Profile WWW
June 28, 2013, 08:25:06 PM
 #1340

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

Hmm.  I've just realized the -S flag, which you said you already tried, includes disabling BFI_INT.  Can you run the OpenCL code on your CPU (-d, -D, or -p flags, see --help)?  Feedback from that might help narrow down the problem to an OpenCL compiler issue or hardware difference.

I tried with the hex editor, and you guessed correctly, it threw an error.   I think this may be beyond me.

What was the error?  I've since tried this on both Windows and Linux and the resulting binary seemed to work (don't know that it disabled BFI_INT.)  Are you sure you overwrote (instead of inserting) and didn't change anything else?

The -S flag crashes me every time. 

I re tried the hex edit, and it did not throw an error this time, I must have screwed it up at first.  But I get the same issue, cpu and gpu hash does not match.  If I run on my cpu, it works fine.
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 ... 173 »
  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!