So I just updated to the most recent version of the miner from Sunny King, and now my ten minute rolling average pps is ~600 pps (custom calculation script) on 8 threads. Woo!
Now to see if that correlates to finding more blocks.
Everyone update and stop bitching about people "stealing blocks", lol.
Edit: I forgot to mention that my previous average about 42 pps. Additionally, I compiled the update will the default options on OSX, running on a quad core 2.2 GHz Intel core i7 on macbook pro.
Did you do this without reducing the maxseivesize? 'cause I think that skews the pps number. ...but there are definitely places all over for optimization... I did not make any changes to the code. To update: check the source out from github here: https://github.com/primecoin/primecoinI'm not a windows guy, so I can't help you with compiling on windows, sorry. |
|
|
|
|
So I just updated to the most recent version of the miner from Sunny King, and now my ten minute rolling average pps is ~600 pps (custom calculation script) on 8 threads. Woo!
Now to see if that correlates to finding more blocks.
Everyone update and stop bitching about people "stealing blocks", lol.
Edit: I forgot to mention that my previous average about 42 pps. Additionally, I compiled the update will the default options on OSX, running on a quad core 2.2 GHz Intel core i7 on macbook pro.
|
|
|
|
|
Also selling 32 Prime coin for 0.01 BTC each. PM me in interested.
|
|
|
|
Oh snap, things be going crazy. |
|
|
|
|
I got mine in last night, everything seems to be working fine.
Thanks!
|
|
|
|
|
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've been getting a bunch of Idle worker warning emails in the last few days, even though all my workers are still submitting shares. I get a notification for all of my workers with notifications on at the same time.
|
|
|
|
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. |
|
|
|
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: 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: 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: 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. 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: 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
There may be a better way, but you could run vanity gen with just the prefix: 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: The '$' looks for matches at the end of a line. |
|
|
|
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! |
|
|
|
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.
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: 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: pko=ecdsa.SigningKey.from_secret_exponent(pk,secp256k1) The above code is heavily based on this post: https://bitcointalk.org/index.php?topic=84238 |
|
|
|
No, as Wolf0 pointed out, I mean a brain wallet, where the private key is sha256(passpharase). You can make them here: https://www.bitaddress.org/ |
|
|
|
Hi,
So I made a brain wallet a little while ago and put some coins in it. Not many (~1-2), but given current prices, I figure it's worth it to try and get at them again. The problem is that I can't exactly remember by passphrase. It was several words with non standard capitalization and letter substitutions. I remember what the base words were, but I can't remember the substitutions. I know the bitcoin address, so my plan is to generate possible passphrases based on what I know, then generate the private keys and corresponding bitcoin address and see if it's mine.
I've written a script in python to do this, but it's slow. It takes about 0.25 seconds/hash, and it should get me what I need eventually, but I would like it to go faster. I am using the ecdsa and hashlib python libraries to generate the keys and addresses, which I believe are implemented in C.
I've looked at the code for vanitygen, but I don't know C that well and there aren't really any comments, so I'm not sure how everything works. Moreover, I have never done anything in OpenCl, so my excursion into that code was fruitless.
So my question is, is there a way to modify vanitygen or oclvanitygen to generate addresses based on trial passphrases, or sha256(trial passphrases)?
I've done a fair bit of googling, but I can't find anyone who has made a program for this purpose. I'm willing to spend some time learning C (and maybe some OpenCL) if necessary.
Thanks
TL;DR: I don't remember by brain wallet, and want to use vanitygen (or part of it) to recover it.
Alternatively, is it possible to use John the Ripper or similar to generate bitcoin addresses and test that way? |
|
|
|
|
Hi,
So I made a brain wallet a little while ago and put some coins in it. Not many (~1-2), but given current prices, I figure it's worth it to try and get at them again. The problem is that I can't exactly remember by passphrase. It was several words with non standard capitalization and letter substitutions. I remember what the base words were, but I can't remember the substitutions. I know the bitcoin address, so my plan is to generate possible passphrases based on what I know, then generate the private keys and corresponding bitcoin address and see if it's mine.
I've written a script in python to do this, but it's slow. It takes about 0.25 seconds/hash, and it should get me what I need eventually, but I would like it to go faster. I am using the ecdsa and hashlib python libraries to generate the keys and addresses, which I believe are implemented in C.
I've looked at the code for vanitygen, but I don't know C that well and there aren't really any comments, so I'm not sure how everything works. Moreover, I have never done anything in OpenCl, so my excursion into that code was fruitless.
So my question is, is there a way to modify vanitygen or oclvanitygen to generate addresses based on trial passphrases, or sha256(trial passphrases)?
I've done a fair bit of googling, but I can't find anyone who has made a program for this purpose. I'm willing to spend some time learning C (and maybe some OpenCL) if necessary.
Thanks
TL;DR: I don't remember by brain wallet, and want to use vanitygen (or part of it) to recover it.
|
|
|
|
|
Ah, thank you. I can't believe I missed that.
|
|
|
|
|
So I ran ./parser allBalances >allBalances.txt. It took a while to run, but didn't throw any errors and seemed to complete normally.
The first 100 lines or so of the output also seem fine, but after that the Bitcoin addresses are all X's: for example:
"35.09900000 0476042f5062d0f4092dcab601b142c0dcf339ef XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 1 Thu May 16 13:26:12 2013 0 Thu Jan 1 00:00:00 1970"
Anyone have any idea why this is happening and how I can fix it? I glanced at the code, but don't really understand that is happening.
Thanks in advance!
|
|
|
|
|
Hi, so I just started doing the vanity mining.
The program started up find and pulled available work and displayed:
"Searching for pattern: "1Aurareus" Reward: 0.096000 Value: 0.000002 BTC/Gkey
Difficulty: 50656515217834
Total value for current work: 0.000002 BTC/Gkey"
So is it only checking the generated keys against the one pattern "1Aurareus", or is it checking for all available patterns. Assumingily, it would be more profitable to check all the available patterns to see if you randomly get it. Is that possible or is the splitkey thing not allowing it. Or am I way off here?
Thanks!
|
|
|
|
|
The pool appears to be down for me on two machines since this morning (possibly earlier). Any word on this? cgminer kicked me to a backup pool in the meantime.
|
|
|
|
|
Show Posts
