 Show Posts
|
|
Pages: « 1 [2] 3 4 5 »
|
<<-- snip -->
Very valuable addition, thank you very much! I'll look into it at the end of the week, when I have more time again.
What results did you observe speed-wise?
The relative speed differences as posted in the code blocks stayed more or less the same so ~ +10 % from compressed to uncompressed (no change compared to original code) ~ +60 % from uncompressed to combined ~ +50 % from compressed to combined I see no reason why these relative speed increases would not work in OpenCL. |
|
|
|
Could anybody post the necessary code changes to allow oclvanitygen to generate compressed and uncompressed keys simultaneously? I suspect the speed increase must be substantial
Thanks!
Your "suspicion" is misplaced. The only calculation in common that would be saved is the calculation of the x coordinate of the public key, which is just a few multiplications. Everything else, from creating the compressed public key parity, creating an address from a compressed public key and checking for the vanity match would be a completely different process. As stated before, this was interesting to research. Unfortunately I don't have a OpenCL environment, so I made the adaptations for CPU only >~/vanitygen$ ./vanitygen 1BTC4me --> normal uncompressed
Difficulty: 15058417127
[531.70 Kkey/s][total 5206528][Prob 0.0%][50% in 5.5h]
[533.98 Kkey/s][total 6267648][Prob 0.0%][50% in 5.4h]
>~/vanitygen$ ./vanitygen 1BTC4me -F compressed --> compressed
Difficulty: 15058417127
[616.63 Kkey/s][total 6103808][Prob 0.0%][50% in 4.7h]
[610.36 Kkey/s][total 7794688][Prob 0.1%][50% in 4.7h]
>~/vanitygen$ ./vanitygen 1BTC4me -F combined --> combined un/compressed
Difficulty: 15058417127
[837.12 Kkey/s][total 8072704][Prob 0.1%][50% in 3.5h]
[843.84 Kkey/s][total 8910848][Prob 0.1%][50% in 3.4h]
>~/vanitygen$ ./vanitygen 1BTC4 -F combined -k
Difficulty: 4476342
Pattern: 1BTC4
Address: 1BTC4iPDG4247a3nmcnUTcLNS1bbwYRgvJ
Privkey: 5J85mEv3tk1HjYBCm6bcKHVEV9NjwtxFg2cVfY6SnhjW616VBvv --> uncompressed result
Pattern: 1BTC4
Address: 1BTC4pnrA9jnJB3usxhaVs4wweQtpcQ7a7
Privkey: KwJX5idP7UVGHQbL1QZRzjPcgYnXv6AkRsBhmuDzhJfvmASRZBQT --> compressed result
Pattern: 1BTC4
Address: 1BTC4caZJqqGZzjEdpbXuX17wyQgv4oRpK
Privkey: KzNUxCmvVui8rLBFY4cMDy7TGeu5MDU7GSfPx1Sevj3RoxkhoL3Q
Pattern: 1BTC4
Address: 1BTC4tkVwqUTCmG5fYexRyAaby3UXyt79R
Privkey: 5HqNmZzdjFPGF94hZGJmdeFBoa2hzLkShXQGajeP8n9CoEz8SzJ
Pattern: 1BTC4
Address: 1BTC4fZk5atAnE7DH6qW3mjP3AdikkNM6Z
Privkey: KzNUxCmvVui8rLBFY4cMDy7TGeu5MDU7GSfPx1SevmVBzAzN6BMR
If you don't mind if the WIF key is compressed or not, there is a substantiation speed increase when hashing both the Uncompressed and Compressed EC-point. With my hack, I'm losing some time on the normal and compressed code execution due to selection overhead. I'll update my repo @ github after some code cleaning :-) Update: Github repro updated  |
|
|
|
tspacepilot it seems this is exactly what I was looking for. Could you tell me where to add the piece you posted?
Thanks!
Nice topic to research. the mayor changes will only have to be made in the function: void *vg_thread_loop(void *arg). In stead of the two options compress and uncompressed a combined flag could to be introduced/added as a valid command line flag. When combined is active, only calculate (uncompressed) EC points for half the buffer. Fill the other half with the equivalent compressed points. for all other calculations use same flag to switch halfway between postprocessing (un)compressed settings. The final address checks can stay the same. In theory.... at least. It will take a bit more work than just porting the example python code........ |
|
|
|
I saw in another thread that someone is able to get 5+ Mkey/s out of their laptop with oclvanitygen. I am sure I am doing something wrong with the parameters trying to get it working, still only getting about 100 Kkey/s using these parameters:
oclvanitygen -f list.txt -D 0:0 -w 512
on a Lenovo laptop with 64bit Win7. According to oclvanitygen I have:
0: i5-3320M CPU @ 2.60GHz
1: Intel HD Graphics 4000
Can anyone share what are your typical input parameters or provide pointers?
It's my guess you are running the opencl vanitygen on your CPU and not GPU. I have laptop with an Intel HD graphic, but never got the right drivers (ubuntu) working to run opencl on the graphic card. But maybe the drivers for windows do work. Could you try to run the cpu version (vanitygen64.exe) an check if the speed increases? With an I5-CPU@2.6G you must be able to get >400kKey on the CPU. |
|
|
|
Helou,
Could someone give some coding support for vanitygen (oclvanitygen)?
I'm using oclvanitygen (GPU) with Linux and I could compile a new version from source code.
So I need some advices for my "problem".
When oclvanitygen found ex "1GeGeA" pattern with -k option (Keep pattern and continue search after finding a match), now it's generate a new random seed and start again from different point.
I need to modify the source code that way, when it found a pattern, it does not generate a random seed value, only increase X value amount to "secret exponent value". So the starting point is quite near the previous one (diff X).
---snip ----
Could someone please give piece of code for me? I'm quite noob to code.
I have look the source code, but it's quite difficult to understand.
Thank you very much!
I Guess what you are looking for kind of kills the purpose of the ECDSA algorithm. The algorithms to find ECSDA points for addition and multiplications are not so straightforward to find points that are 'close'. The result is also hashed with SHA256, creating a big change in the result for each minor change. All the code you need for your problem is available, its called vanitygen, unfortunately >99% of the solutions/time is waisted....... |
|
|
|
Dear Loyal Players
During last 2 years we have tried our best to offer you the best service. We never refused a cash out or never used any bots on the website. We have paid over 30K $ because of large amount of freerolls on the website in that period.
We never had a plan to stop our service but after last DDOS attack on the website, our Server provider asked us to change our plan to professional so that they can install the DDOS protection on the new server. While the new server costs near 200$ a mount also moving the SSL and all security layers to the new server take us many time.
We are sorry to say that we have decided to stop our service. It was our life for last 2 years and we have very sad moments now.
All the users information are safe and secured so there is no need to be worry about your data.
If anybody is interested in buying K8Poker please contact [support [at] k8poker [dot] net].
We will start to send the users balances as soon as we found enough sources. Thanks for your patient.
Regards
Alex
K8Poker.net
I was looking for an update like this for weeks on your facebook and twitter pages. It would have been nice if you also used these channels to update your loyal players. It's a pity you've decided to stop. Please keep you players updated until all accounts are settled. |
|
|
|
The util.c source code holds a function to decrypt, but I cannot find where a call to this function is actually made. Are you referring to vg_decode_privkey_any ? That gets called from keyconv. Usage is keyconv <encrypted key>. Should prompt you for password. Yep that's the one I was looking for |
|
|
|
In short, it is part of the vanitygen package, but not needed if you only generate the keys for own use.
Unless you make use of the -e parameter to encrypt the private key. It was my understanding that you then need to make use of keyconv.exe to decrypt that private key. There however seems to be some problems as I've had several keys where it worked i.e. the decrypted private key but I've also had about 5 keys now where the decrypted private key was shown as invalid when trying to import it into a wallet. I never actually looked at this decryption of the private key. This is more or less a security action, I'm not sure how (or even if) this links into the actual vanitygen algoritms. One thing that i found interesting, and I will look into this a bit further, is that both vanitygen and keyconf have the -e and -E for password encryption. None of these programs have a setting for the decryption. The util.c source code holds a function to decrypt, but I cannot find where a call to this function is actually made. |
|
|
|
Thanks, I never saw that parameter before (but then again, I'm not into altcoins). Still, I'm right that keyconv is a separate python package, right? That's not part of vanitygen is it?
The keyconv as can be found in the repositories that hold vanitygen is not a python package. I have not checked if python holds a package with the same name, but that is pure coincidence. This software can be used if you need or provide vanity address generation for a third party in a secure way. The two keys that you end up with can be combined with this tool to the WIF key that generates the correct vanity address. In short, it is part of the vanitygen package, but not needed if you only generate the keys for own use. |
|
|
|
tspacepilot@god:~/src/vanitygen$ ./vanitygen -v 1WALNUT Yeah, probably just bad luck then. 7-character prefix will take a while on most hardware and the bad end of variance scales accordingly. If you're keen on having it, generate a private/public key pair, post the public key here, and maybe some kind folks will attempt a search for you. See the discussion on split key generation a page or 2 back for details. Right on, for the moment I've got no rush so I'll just let it crank away for a while. If I get desperate sometime a week or so from now then I may just take you up on that. Thanks TheRealSteve. I'm not sure what version you are running, but I checked on my system: $ ./vanitygen -v 1WALNUT
Prefix difficulty: 888446610538 1WALNUT
Difficulty: 888446610538
$ ./vanitygen -v -i 1WALNUT
Prefix difficulty: 27763956579 1WALNUT
The difficulty with and without the -i (ignore case) is different, and my ignore case is giving the same difficulty as your code dump. It seems your version is looking for the all caps, but is showing difficulty equal to my ignore case command. So all the probability is calculated based on a wrong number, it will probably take about 888/27 = 38 times longer to find a single key. based on ~350Kkey/s about 20 days to hit the 50% |
|
|
|
I did a little code review, The following can be found in the 'vanitygen.c' file vxcp->vxc_delta=vxcp->vxc_delta-step;
for (j=0;j<step;j++){
memcpy(vxcp->vxc_binres+1,MDBufChar+j*32,20);
switch (test_func(vxcp)) {
case 1:
npoints = 0;
rekey_at = 0;
i = nbatch;
j = step;
break;
case 2:
break;
goto out;
default:
break;
}
vxcp->vxc_delta++;
}
}
The test_func(vxcp) returns a "1" when a match is found, all counters are reset, so it is not evaluating the remaining codes. When using the -k (keep searching) and the -q (just don't want to many screen updates) it seems that all 256 keys in the batch are evaluated. if the following lines are remarked. case 1:
// remark npoints = 0;
// remark rekey_at = 0;
// remark i = nbatch;
// remark j = step;
break;
Since it is now determining the checksum for each match the speed is not increased by 256  but on my system the output file is about twice the size after a short run. |
|
|
|
Probably the reason the "1" and "1A" are relative equal in speed, statistically each batch will have about 10 "1A" matches.
Just to correct myself, 256 /58 (base 58) is just over 4 not 10 |
|
|
|
Shouldn't every ECDSA key -> pubkey -> hashamahash -> base58check- > address be valid?
This is correct, every key should give a valid address... that is if the all calculations were fully completed. vanitygen doesn't complete address for the check-sum part. These last bytes are all set to 0 to make sure the length is correct. The first part of the generated address ~25 chars will not change due to this check-sum. By skipping this part a lot of speed is gained when searching for longer match. (this part is actually always executed in the -regex mode, the speed difference can be observed) Only when a match is found the checksum is calculated en and the WIF and final address is stored. When matching a valid bitcoin address i.e. just the leading "1" this match requires the check-sum to be generated. This part is currently not as optimized for speed as the generator part; for the function of vanitygen this optimization is actually not needed. On the CPU the hashing is done in batches of 256 ECDSA keys, I have to recheck the code but I think that when a match is found the remaining 255 might no longer be checked/validated. The ECDSA part of the generation is more than 70% of the cpu time. Probably the reason the "1" and "1A" are relative equal in speed, statistically each batch will have about 10 "1A" matches. The ECSDA engine and the hashing up to the checksum is very optimized. When optimizing the checksum and base58 part as well, skipping the match check, just storing all results to file would make this prog a faster 'any address' generator. |
|
|
|
I was thinking you could generate a private key on electrum, then offload the vanity address to someone else to generate then that has better processing power- or pay to have it done.
yep that is what this pool does. If you use vanity pool, you are risking the exposure of the private key?
this is a three stage operation. 1- your create a key palr (priv key, publc key) that also yields a non vanity bitcoin address, for example on electrum, preferably more secure on your own system. 2- upload the request for a vanity address and the public key to this pool or another service that has the processing power. 3- retreive the priv key from this pool. The actual address generation routine only uses public keys. combine this priv key(unsecure) with your priv key(secure) to generate a new priv key(secure). (an online utitlity to do this is here gobittest(dot)appspot(dot)com/VanityAll but since it is on the internet it is less secure than running the keyconv util) this new priv key gives you the vanity address. |
|
|
|
Shouldn't it be possible to use a master public key to use to generate the vanity key from?
This way, the private key is never exposed.
That would only be needed if you don't generate the address yourself. You will need the private key to get access to your wallet. The software has switches for this. A master public key that only you have the private key for can be used in the generation process. The result private key (wif format) and your private key (also wif) can be combined using the keyconv utility. This private key is now only known to you. There is even a pool for this @ vanitypool(dot)appspot(dot)com |
|
|
|
thanks, btw if we change date and time of our offline laptop before we generate address would that make our address more secure ?
There are mulitple types of security here. First, do you trust the source where you downloaded the software.... ? I build from the source-code itself to be sure my executable doesn't do anything unexplained. The second type of security has to do with the ECSDA key generation. This is linked to your SSL library. Since it uses entropy to make key generation unique, it would even be hard for your computer to regenerate the same result. Modern entropy uses time, (cpu) temperature readings, harddisk head locations etc etc to make it unique. Then there is the security of you home network. Etc etc. As you can see if you play with the program is that for each extra character you add the time to get the address is multiplied by 60. Even if you generate an address with the first 9 char in a preferred state, in order to get access to this address anyone else will have to generate all 35 chars. |
|
|
|
Testing keyconv... everything goes good until I try to generate the final address with the privkey+part privkey... it just says unrecognized key format. Any workarounds?
The way it's setup is that it only combines WIF key's. Not the ECSDA private key's. |
|
|
|
I've used cross compile to generate the Windows binaries from Ubuntu.
This seems to work for keyconv, I'm still struggling with vanitygen itself.
I've put the binary in my repo at github, but since github doesn't support single file download,
the whole repo needs to be downloaded as zip.
This version of keyconv has the -X switch to support multiple cryptocoins.
It also supports combining compressed WIF format keys.
Right click the file you want to download and then click 'Save link as...' and then save the link with its extension if it isn't already there - mostly it will show automatically, for eg:- keyconv.c for keyconv.  I think you meant Lifeboat's vanitygen. Try to download full zip or just do like I said above.  ~~MZ~~ I checked the Lifeboat's download, but that one does not contain the keyconv utility. I therefor mean my own version of keyconv . @ https://github.com/kangaderoo/vanitygen |
|
|
|
Is this version of keyconv avaliable for windows anywhere?
Still haven't figured it out how to compile this for Windows, or where to download it already compiled... Can someone give a hand? I've used cross compile to generate the Windows binaries from Ubuntu. This seems to work for keyconv, I'm still struggling with vanitygen itself. I've put the binary in my repo at github, but since github doesn't support single file download, the whole repo needs to be downloaded as zip. This version of keyconv has the -X switch to support multiple cryptocoins. It also supports combining compressed WIF format keys. |
|
|
|
snip
Yes I am aware of how it works, I am just wondering where the "latest" repo is. (with support for compressed keys etc) And if possible I would like some binaries... but not a requirement. As far as I know there is no longer a single driving force for this project. OP has been silent for quite a while. I did some work on it, but that was just to enhance my knowledge on ECDSA and coin address generation in general. My Dev-Env. does not support OCL and since it is tuned to my own linux system it would need work to make it more general. I'm afraid all of the repo's out there are a bit fragmented. |
|
|
|
|
