I manged to reproduce the bug. It happens only for uncompressed addresses. It is not link to CUDA 8 or 10. It happens also if CPU is used alone or if GPU is used alone. But with a probability of ~1/2000  I don't know if it is also linked to the prefix length (I don't think) it is difficult to reproduce with longer prefix due to the small probability. I'll try to debug this... |
|
|
|
|
No I didn't manage to reproduce the issue. If you use a prefix with 4 char and also starting with a T you can expect that the bug will occurs 58 times less. It could be interesting to test with 'BTC' prefix , for instance, more probable that 'TeS'.
|
|
|
|
Hello
By default it is the dedicated memory of the graphics processor that is used but would it be possible also to force the use of the shared ram? Could this increase the speed of execution or am I wrong?
Hello VanitySearch uses the GPU global memory to store hash160 that partially match (16bit lookup table) the desired prefixes, the transfer to the RAM of the motherboard is done by the DMA, then the CPU checks all returned hash160 against the complete prefix. There is no really shared memory that can be accessed directly by the CPU and the GPU (may be it exists on embedded GPU). Transfers are mainly done by the DMA trough the PCIe. What we usually called "shared memory" in CUDA is a GPU memory shared inside a WARP. A WARP is a block of 32 threads (or more on powerfull GPU) executed on a stream processor. |
|
|
|
the mistake is still there on rtx 2070 with -g 144 and with -g 288
mmm... Strange... I will try to make a long test. It would be great if other uses can also test this case: VanitySearch.exe -gpu -b -o vanity.txt 1TeSand run it up to find at least ~10000 matches (~2^34 keys) in order to confirm that it comes from VanitySearch and not from your driver and/or hardware ! on Cuda 8 with -g 4 everything seems ok VanitySearch is running worry-free even with -b and no error message everything seems ok
OK, that's confirm that with -b option and the default setting, your old GPU exceed the timeout. Thanks for the reports  |
|
|
|
The check function checks only one kernel call, here the problem happens after many calls. I tried with my GTX 1050 and I didn't manage to reproduce the issue. ~2^34 keys, ~10000 matches without problems. Could you try on the RTX 2070 to launch with -g 144 to see if it changes something ? The most annoying is for those running only on CUDA 8 (like me with my old hardware) but who can’t launch with -b Vanitysearch instead no errors without -b it works well
Did you try with -g 4 ? |
|
|
|
|
Few more questions:
Does the bug concerning the "wrong generated key" is reproducible and do you always get a wrong key every ~2500 matches ?
Does it happen without the -r option ?
|
|
|
|
Hello Thanks for the report. I try with both CUDA8 and CUDA10 using -b option and I generated ~2^33 keys with the same pattern as you did. It has also found ~5000 matches without error in my case using a GTX 645. Concerning the timeout of your GT 520M try with -g 4, a CUDA kernel has a limit of execution time, searching with -b is longer. I will make more test on other hardware ASAP. C:\C++\VanitySearch\x64\Release>VanitySearchCUDA8.exe -r 100000 -b -o output.txt -gpu 1TeS
VanitySearch v1.11
Difficulty: 4553521
Search: 1TeS [Compressed or Uncompressed]
Start Sat Apr 6 17:07:14 2019
Base Key: Randomly changed every 100000 Mkeys
Number of CPU thread: 3
GPU: GPU #0 GeForce GTX 645 (3x192 cores) Grid(24x128)
13.944 MK/s (GPU 12.859 MK/s) (2^33.43) [P 100.00%][99.00% in 00:00:00][5049]
C:\C++\VanitySearch\x64\Release>VanitySearch.exe -r 100000 -b -o output.txt -gpu 1TeS
VanitySearch v1.11
Difficulty: 4553521
Search: 1TeS [Compressed or Uncompressed]
Start Sat Apr 6 17:33:01 2019
Base Key: Randomly changed every 100000 Mkeys
Number of CPU thread: 3
GPU: GPU #0 GeForce GTX 645 (3x192 cores) Grid(24x128)
14.804 MK/s (GPU 13.716 MK/s) (2^33.51) [P 100.00%][99.00% in 00:00:00][5315]
|
|
|
|
That's strange, on my GTX 1050 Ti, CUDA8 is slightly slower (~3%) than CUDA10. On my GTX 645 it is similar. Did you wait that key rate is well stabilized ? C:\C++\VanitySearch\x64\Release>VanitySearch.exe -t 0 -stop -gpu 1Testtttt
VanitySearch v1.11
Difficulty: 2988734397852221
Search: 1Testtttt [Compressed]
Start Thu Apr 4 14:18:30 2019
Base Key:28B34C47FDB37FB3175059450AFD3D301F682B2F16217EEE25AD83A42939A1B6
Number of CPU thread: 0
GPU: GPU #0 GeForce GTX 1050 Ti (6x128 cores) Grid(48x128)
226.483 MK/s (GPU 226.483 MK/s) (2^32.65) [P 0.00%][50.00% in 106.4d][0]
C:\C++\VanitySearch\x64\Release>VanitySearchCUDA8.exe -t 0 -stop -gpu 1Testtttt
VanitySearch v1.11
Difficulty: 2988734397852221
Search: 1Testtttt [Compressed]
Start Thu Apr 4 14:19:17 2019
Base Key:290C9148BE403FE1904ACA72641003E9B04507E30A054DA64DB732963C3080D0
Number of CPU thread: 0
GPU: GPU #0 GeForce GTX 1050 Ti (6x128 cores) Grid(48x128)
219.406 MK/s (GPU 219.406 MK/s) (2^32.04) [P 0.00%][50.00% in 109.8d][0]
|
|
|
|
|
Yes, P2WPKH-P2SH (starting with '3') addresses are slower, there are 2 hash160 to compute per address, only 1 for P2PKH (starting with '1') and P2WPKH-BECH32 (starting with 'bc1q').
Edit:
Interesting test, you notice also that the -r option is costly for nothing...
|
|
|
|
1.11 available for CUDA8  |
|
|
|
Hello, I just published the release 1.11 of VanitySearch: https://github.com/JeanLucPons/VanitySearch/releases/tag/1.11- Added support for segwit address P2SH and BECH32 I upload the windows release for CUDA8 asap. C:\C++\VanitySearch\x64\Release>VanitySearch.exe -stop -gpu 3Happy
VanitySearch v1.11
Difficulty: 264104224
Search: 3Happy [Compressed]
Start Wed Apr 3 08:50:51 2019
Base Key:D1D33873F77889F1BF84683A9119A2B369758438EB1D6256E56504497F9475E7
Number of CPU thread: 7
GPU: GPU #0 GeForce GTX 1050 Ti (6x128 cores) Grid(48x128)
129.830 MK/s (GPU 113.242 MK/s) (2^27.95) [P 62.59%][70.00% in 00:00:00][0]
Pub Addr: 3HappypJDDfhbj5HasnFmctzd8Up7B5tLR
Priv (WIF): p2wpkh-p2sh:L3q4EBHk5eiuxhsNagsmY5aK8sCNd6zdh6gmqpVG6S666GbvNgcP
Priv (HEX): 0xC5351D98B0B2DE1BD6B7CACADA9A2BE4E09B849FB8816D1CEEC5A08C63A3E837
C:\C++\VanitySearch\x64\Release>VanitySearch.exe -stop bc1queen
VanitySearch v1.11
Difficulty: 1048576
Search: bc1queen [Compressed]
Start Wed Apr 3 08:56:32 2019
Base Key:6F907FDE30067DCDE802739E47C6463FE49C32791242458C2D141212DB107A55
Number of CPU thread: 8
Pub Addr: bc1queenu8kq0vjrl509w88mwefdu4pztkdvlst4at
Priv (WIF): p2wpkh:L24UVC7ZYgYjy4cStQvBHD3quJkeYN3xHYBqFjTYjJjwmht84jsg
Priv (HEX): 0x906F8021CFF9823217FD8C61B839B9BED612AA6D9D065AAF92BE4C79F5251BBA
Thanks for testing |
|
|
|
You mean a public address starting with 3 I guess?
Right |
|
|
|
Just curious, why P2SH? AFAIK there's no benefits of P2SH over legacy addresses if it's only 1 on 1, and you pay more fees. P2SH with Segwit would be great though  It is a first attempt, this is just to allow to run VanitySearch like this (for those who want a private address starting with 3). C:\C++\VanitySearch\x64\ReleaseSM30>VanitySearch.exe -stop 3Priv
VanitySearch v1.11
Difficulty: 4553521
Search: 3Priv [Compressed]
Start Tue Apr 2 07:43:52 2019
Base Key:B0A317C56CF0CF3C63E118687C153CD1336F2D5DCE33A3ADB3CE5E4EEA401436
Number of CPU thread: 8
Pub Addr: 3PrivG5uq7hwXLyAHbYkFTnFkzx1FEWQdf
Priv (WIF): p2wpkh-p2sh:L2wAVD273GwAxGuEDHvrCqPfuWg5wWLZWy6H3hjsmhCvNVuCERAQ
Priv (HEX): 0xAA83217B3A11FCCFF8142EF0681AD774D7AB6822F574C4BB99CBF9B9DD01E7F2
For 2to2 segwit, I need to implement split private keys then generate a 2to2 address from 2 given public key, this is more complex but I will try to do it. That has no sense that VanitySearch output 2 full private keys in the same file, no ? One question, 2to2 segwit is possible only with BECH32 format (bc1...) or it is also possible with Base58 (3...) ? |
|
|
|
Hello, Lots of interesting features to add I think I will work first on P2SH (1to1) add (may be) segwit addresses. |
|
|
|
|
Ok, that means that the requester must know how to reconstruct the final private key.
Does Vanity pool support the needed methods ?
I just had a quick look on the site and there is not information on how to submit the partial private key (which format to use) and the reconstruction method.
|
|
|
|
Yes that could be interesting. But as we start with an offset (the given public key), can we still apply symmetry and endomorpshim optimization ? |
|
|
|
|
Just to be more precise. VanitySearch is not a brain wallet and you do not have to recall the password used. The password is just used to generated a base key and to hack the final private key you have to compute up the 'prefix difficulty' for each 'bad password' you will try.
|
|
|
|
How about if you generated a vanity address? Would it be more feasible for someone to crack the private key if they used the same vanity address generator? Or are random generators so good these days that any bias is negligible?
This is a good question. Concerning VanitySearch if you use a passphase seed, a base key is generated and used to generate addresses up to reach the desired prefix (similar to BIP38 and BIP44 derivation paths), no PNRG is used. Trying to find the key would require to find the seed and to compute until the prefix is reached. That means that to find a private key you have to perform (in average) 'prefix difficulty' time 'number of possible seed' iterations, which is huge. A tool such as john the ripper that generates password can beat weak passwords on system using fast password encryption algorithms (such as MD5) but in the case of vanity addresses, you need for each password to run up to the prefix difficulty. In other words, this is unfeasible. |
|
|
|
|
Show Posts
