Topic: Vanitygen: Vanity bitcoin address generator/miner [v0.22] - page 126. (Read 1153691 times)
Seems to be a lot of problems with it, and it hasn't kept up with FPGAs and ASICs
Why bother, just use vanitygen or oclvanitygen (for GPU). The tool is already written, has a bunch of nice features and it is fast.
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.
THis guy claims to have it working on a 7970, by disabling BFI_INT.
https://bitcointalksearch.org/topic/m.695201
How do I disable BFI_INT ?
https://bitcointalksearch.org/topic/m.695201
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
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 ?
You are missing that cases differ in many times more bits
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 [email protected] 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
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.
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 [email protected] 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.
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.
Still looking to fix this endless loop bug with the 7970. It crashes when I try to use safemode.
Anyone have advice?
Anyone have advice?
Same thing on my 7970. Damn,
Still looking to fix this endless loop bug with the 7970. It crashes when I try to use safemode.
Anyone have advice?
Anyone have advice?
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!
How to generate an address similar to the 1ABC**************************ABC ?
* - A random simbol
* - 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
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$'
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.
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.
How to generate an address similar to the 1ABC**************************ABC ?
* - A random simbol
* - 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
How to generate an address similar to the 1ABC**************************ABC ?
* - A random simbol
* - 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
How to generate an address similar to the 1ABC**************************ABC ?
* - A random simbol
* - A random simbol
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.
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!
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.
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.
However it think the easiest is if python generates the pontential passphrases, which you then run through
sha256sum and recode to bitcoin base58. sha256sum is from coreutils.
sha256sum and recode to bitcoin base58. sha256sum is from coreutils.
It is not quite that easy. After sha256 you have to do an elliptic curve multiply of the bitcoin curve's generator point by the private key to derive the public key. Then DER-encode that point, sha256 and then ripemd160 it. Then base58check-encode.
refer_2_me, I would do it all in one script and not involve OpenCL. If you're actually "close" to the passphrase, it seems like a relatively naive CPU implementation will find it quicker than the time it would take you to develop and test the OpenCL code (unless you're really interested in learning OpenCL and want to do it for fun.)
I am surprised your Python script got such poor performance. If you can post it (omitting passphrase generation) maybe somebody can optimize it.
Thanks for your reply.
What i'm doing is (roughly) the following:
Code:
import sys
import os
import hashlib, binascii
import ecdsa
secp256k1curve=ecdsa.ellipticcurve.CurveFp(115792089237316195423570985008687907853269984665640564039457584007908834671663,0,7)
secp256k1point=ecdsa.ellipticcurve.Point(secp256k1curve,0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798,0x483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8,0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141)
secp256k1=ecdsa.curves.Curve('secp256k1',secp256k1curve,secp256k1point,(1,3,132,0,10))
def gen_keys(string):
'''
Generate the private key and address for the given input string using ecdsa
Arguments:
string -- input string
Return:
private_key, addr -- private key and BTC address
'''
pk_hex = hashlib.sha256(string).hexdigest()
pk = int(pk_hex,16)
pko=ecdsa.SigningKey.from_secret_exponent(pk,secp256k1)
pubkey=binascii.hexlify(pko.get_verifying_key().to_string())
pubkey2=hashlib.sha256(binascii.unhexlify('04'+pubkey)).hexdigest()
pubkey3=hashlib.new('ripemd160',binascii.unhexlify(pubkey2)).hexdigest()
pubkey4=hashlib.sha256(binascii.unhexlify('00'+pubkey3)).hexdigest()
pubkey5=hashlib.sha256(binascii.unhexlify(pubkey4)).hexdigest()
pubkey6=pubkey3+pubkey5[:8]
pubnum=int(pubkey6,16)
pubnumlist=[]
while pubnum!=0: pubnumlist.append(pubnum%58); pubnum/=58
address=''
for l in ['123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz'[x] for x in pubnumlist]:
address=l+address
return pk_hex, '1'+address
if __name__ == '__main__':
#my passphrases to try, generated in another script
wordlist = ( word.strip() for word in open(sys.argv[1]).readlines() )
for word in wordlist:
priv_key, addr = gen_keys(word)
if addr == '1...........': #my bitcoin addresss
print 'Found it!\nPrivate Key:', priv_key, '\nAddress:',addr
sys.exit()
So on a single CPU, it takes about 0.25 seconds for each pass phrase that I check (4 per second). I figure that I have a few million to test (this may be way off), so it seems like it should be worth some time.
I've profiled the code using cProfile and I found that 0.23 seconds of the execution comes from a single line:
Code:
pko=ecdsa.SigningKey.from_secret_exponent(pk,secp256k1)
The above code is heavily based on this post: https://bitcointalksearch.org/topic/simple-script-to-generate-address-from-private-key-84238
However it think the easiest is if python generates the pontential passphrases, which you then run through
sha256sum and recode to bitcoin base58. sha256sum is from coreutils.
sha256sum and recode to bitcoin base58. sha256sum is from coreutils.
It is not quite that easy. After sha256 you have to do an elliptic curve multiply of the bitcoin curve's generator point by the private key to derive the public key. Then DER-encode that point, sha256 and then ripemd160 it. Then base58check-encode.
refer_2_me, I would do it all in one script and not involve OpenCL. If you're actually "close" to the passphrase, it seems like a relatively naive CPU implementation will find it quicker than the time it would take you to develop and test the OpenCL code (unless you're really interested in learning OpenCL and want to do it for fun.)
I am surprised your Python script got such poor performance. If you can post it (omitting passphrase generation) maybe somebody can optimize it.
while running oclvanitygen -d 0 -p 0 -o output.txt 1R
results in
C:\Users\admin\Desktop\vanitygen_catalyst\32>oclvanitygen -d 0 -o output.txt 1R
Difficulty: 1353
Match idx: 0
CPU hash: b3b8b1f62fb59e659835af2b81238fd979ca7e15
GPU hash: 049ae2c66df6d65bb092caa95c759c0599542a13
Found delta: 7338843 Start delta: 1
[3.61 Mkey/s][total 7340032] M
atch idx: 0
CPU hash: 22c34ee82b97f5b8af8ec9c7d2b9cd3b2e2b0421
GPU hash: 04afbde26e27f40663e0ce86223409a873019ff1
Found delta: 7335852 Start delta: 1
[5.32 Mkey/s][total 14680064] M
atch idx: 0
CPU hash: 47aa2162ee34797c81c0799254d7b5b266e4d5f1
GPU hash: 049381dea7d7d0638e44a8f0d9f2bc6e10d3ca4c
Found delta: 7326918 Start delta: 1
[6.09 Mkey/s][total 22020096] M
atch idx: 0
CPU hash: 6635552c18744c27a9f1976801f8439e406abdc3
GPU hash: 04ae7a508a7e8087b54b0947d46186c8f330c875
Found delta: 7338098 Start delta: 1
[6.58 Mkey/s][total 29360128] ^
And it just goes on forever and ever. but if i do it with the cpu version it work for perfect in no time. i read through form and have not noticed any thing posted about this.
results in
C:\Users\admin\Desktop\vanitygen_catalyst\32>oclvanitygen -d 0 -o output.txt 1R
Difficulty: 1353
Match idx: 0
CPU hash: b3b8b1f62fb59e659835af2b81238fd979ca7e15
GPU hash: 049ae2c66df6d65bb092caa95c759c0599542a13
Found delta: 7338843 Start delta: 1
[3.61 Mkey/s][total 7340032] M
atch idx: 0
CPU hash: 22c34ee82b97f5b8af8ec9c7d2b9cd3b2e2b0421
GPU hash: 04afbde26e27f40663e0ce86223409a873019ff1
Found delta: 7335852 Start delta: 1
[5.32 Mkey/s][total 14680064] M
atch idx: 0
CPU hash: 47aa2162ee34797c81c0799254d7b5b266e4d5f1
GPU hash: 049381dea7d7d0638e44a8f0d9f2bc6e10d3ca4c
Found delta: 7326918 Start delta: 1
[6.09 Mkey/s][total 22020096] M
atch idx: 0
CPU hash: 6635552c18744c27a9f1976801f8439e406abdc3
GPU hash: 04ae7a508a7e8087b54b0947d46186c8f330c875
Found delta: 7338098 Start delta: 1
[6.58 Mkey/s][total 29360128] ^
And it just goes on forever and ever. but if i do it with the cpu version it work for perfect in no time. i read through form and have not noticed any thing posted about this.
I've come across this too with a full uninstall of newer drivers (removal tool) and downgrading to 12.8.
The only solution I can use to avoid the loop above is to run in safemode with the -S flag.
This does run a lot slower than normal.... however it is still a lot faster than my CPU.
I ran into this issue myself - was mining for a prefix 1piit79 on a 7970 and didn't realize it was a bug until I tried 3 times (and wasted quite a lot of GPU time - 50% tok ~7h
)Funnily enough it worked just fine when I ran it on 5870 (and it was surprisingly just a bit slower than the 7970).
I am having the same issue with my 7970. Does anyone have a fix for this? Id love to use this, but nothing works. safe mode isnt working for me.
Jump to: