ubuntu error compile

[broka77]

hello

I can not compile on ubuntu source code gives an error gcc can lay out a binary for ubuntu? that binar that the branch below does not work for me ... and another question in what format should the prefixes in the file be? with "1" or no unit?

[broka77]

make gpu=1 all /usr/local/cuda-10.0/bin/nvcc -maxrregcount=0 --ptxas-options=-v --compile --compiler-options -fPIC -ccbin g++ -m64 -O2 -I/usr/local/cuda-10.0/include -gencode=arch=compute_60,code=sm_61 -o obj/GPU/GPUEngine.o -c GPU/GPUEngine.cu In file included from /usr/local/cuda-10.0/include/cuda_runtime.h:83, from : /usr/local/cuda-10.0/include/crt/host_config.h:129:2: error: #error -- unsupported GNU version! gcc versions later than 7 are not supported!

error -- unsupported GNU version! gcc versions later than 7 are not supported!

^~~~~

[JeanLucPons]

Hello, Yes. As I wrote in the readme, the CUDA SDK (nvcc) does not support all gcc versions so you need to install an older release for nvcc and make a link to this old release in /usr/local/cuda/bin. Have a look here for supported gcc version: https://docs.nvidia.com/cuda/cuda-installation-guide-linux/index.html

[JeanLucPons]

A binary is available here: http://zelda38.free.fr/VanitySearch

[broka77]

this binary not work ubuntu (

[JeanLucPons]

This is the problem with Linux binary. They depend on your distribution. What is your release of Ubuntu ?

[broka77]

18.04

[broka77]

run ./VanitySearch access denied

[JeanLucPons]

access denied ? check the right of your file. try: chmod a+x VanitySearch

[broka77]

error error while loading shared libraries:libcuda.so.8.0: cannot open shared object file: No such file or directory Cuda 10.0 installet on Ubuntu system

[JeanLucPons]

Yes, this binary is linked with cuda sdk 8.0 Could you execute the following command and post the result. cat /usr/local/cuda/include/host_config.h | grep __GNUC

[broka77]

command not found

[JeanLucPons]

You may have type something wrong, no ? cat /usr/local/cuda/include/host_config.h | grep __GNUC or vi /usr/local/cuda/include/host_config.h

And search the line: if GNUC > 5

warning -- unsupported GNU version! gcc versions later than 5 are not supported!

endif / GNUC > 5 /

This will give which gcc you need

[broka77]

host_config.h it does not have if GNUC > 5 can you compile to cuda 10?

[JeanLucPons]

I'll try I let you know

[broka77]

thank you very much I will wait!

[broka77]

and I have another question about the prefixes in the file in what format should they be? start with "1" or without 1 unit ...

[JeanLucPons]

Could you try with this file: http://zelda38.free.fr/libcudart.so.8.0 You copy it in same directory than VanitySearch and you set LD_LIBRARY_PATH as : export LD_LIBRARY_PATH=. Yes prefixes start with 1 as for the command line. But It would be better if you try to compile by yourself.

[broka77]

./VanitySearch -gpu -t 31 -gpuId 0,1 1H33245appy Start Tue Mar 12 12:16:43 2019 Difficulty: 173346595075428800Search: 1H33245appy Base Key:F0FAD6AF56A60C28D29F37BE7F758EE5B74A86A62D343ED59243F184CC54558F Number of CPU thread: 31 GPU: GPU #1 GeForce GTX 1080 Ti (28x128 cores) Grid(224x128) GPU: GPU #0 GeForce GTX 1080 Ti (28x128 cores) Grid(224x128) GPUEngine: Kernel: invalid device function0.00%][50.00% in 124.443y][0]

[broka77]

and stop work

[JeanLucPons]

I upload a new binary http://zelda38.free.fr/VanitySearch compiled with 6.1 capability Could you try it.

[broka77]

GPUEngine: Kernel: invalid device function0.00%][50.00% in 124.443y][0]

[JeanLucPons]

could you just execute ./VanitySearch -l and post the result

[broka77]

./VanitySearch -l GPU #0 GeForce GTX 1080 Ti (28x128 cores) (Cap 6.1) (11178.5 MB) (Multiple host threads) GPU #1 GeForce GTX 1080 Ti (28x128 cores) (Cap 6.1) (11173.4 MB) (Multiple host threads)

[JeanLucPons]

Try this link http://zelda38.free.fr/VanitySearch61 , for the last download you may get the same old file due to cache.

[broka77]

Work thanks !!)) but my file prefix have 146k prefix Start Tue Mar 12 12:39:29 2019 Search: 182 prefixes (Lookup size 182) Base Key:BC766FDBB646E8954D94BE478CE1151259CB3C6BB9E1C9E776848857C692D2F9 Number of CPU thread: 30 GPU: GPU #1 GeForce GTX 1080 Ti (28x128 cores) Grid(224x128) GPU: GPU #0 GeForce GTX 1080 Ti (28x128 cores) Grid(224x128) 30.076 MK/s (GPU 0.000 MK/s) (2^26.84) [P 0.00%][50.00% in 3.58204e+28y][0] Warning, 146556 items lost (try to search with less prefixes)

Warning, 146992 items lost (try to search with less prefixes)

[broka77]

if the -u option is not worth it, does the program generate compressed addresses?

[broka77]

It is planned to support compressed addresses and options for both those and those (both) ?

[JeanLucPons]

Yes if -u is unspecified, it search only compressed addresses Yes for the both option it can be done.

But there is problems with your output: I don't understand why with a 146k prefix file you got only 182. Then you have a warning, about lost prefixes. And the GPU rate is 0 ?

What your prefix file look like ?

Note: If you want to attack full addresses, the file must contains complete addresses like this:

1GrYzyD7era9b6rLMNiUSYUtf5zYzquP2W 19NKgpEW5X2EP7TzCEmWhV3CxW4KfxAke8 19khNmwfhQpvdafxkzApQEZUp9AwQKYwRe 1CvtydPDXjvHTs7YQ4oFjZtFfbGhR1tMNM 1NMRrgoLSJHVMiUaugewBnpD4WYChCLx5X 14CCPi7eSiZJCcQFierdcxJRZhFGd5cLS8 15JwM16iEyzEsiym5yjJkC6gkKuhtZ4aou 142WM5MnF6mQDn32pfCPJVbfaCij3LD9Mi ...

and the output should looks like (ex for 100003 addresses):

pons@linpons:~/VanitySearch$ ./VanitySearch -gpu -gpuId 0,1 -i inputfull.txt Start Tue Mar 12 12:46:00 2019 Search: 100003 prefixes (Lookup size 51290) Base Key:3F55185460CC133E65BDE2BFED87E86E0514329A5218A81A882942DEFC393B52 Number of CPU thread: 1 GPU: GPU #0 Quadro 600 (2x48 cores) Grid(16x128) GPU: GPU #1 Quadro 600 (2x48 cores) Grid(16x128) 22.495 MK/s (GPU 20.966 MK/s) (2^26.59) [P 0.00%][50.00% in 1.42799e+33y][0]

If you really want to try to attack full addresses, don't waste energy, it is very very very unlikely that one collision is found...

[broka77]

work, all be fine thanks!

[broka77]

Speed 1141.318 MK/s

[broka77]

segmentation error memory stack flushed to disk issued a program after a while

[JeanLucPons]

The only way to try to reproduce the bug is that you search using a seed in order that I know the base key and that you send me your file in order to reproduce the bug otherwise it will be difficult to debug.

[broka77]

Thank you very much for your help! If you make updates, please make binaries for ubuntu cuda 10

[JeanLucPons]

OK The program still crashes, it is reproducible ? How many key are generated before crashing (2^??) ?

[broka77]

rebooted system program, ceased to crash ... writes 1157.303 Mk / s 2 ^ 41.10 P 0.00%. 50% in 2.77548 + 31y)))

it is bad that statistics are not indicated how many ALREADY keys are generated

[broka77]

program generated base key + 1 or completely (totally) random key ?

[JeanLucPons]

The number of generated are here but as exponential format 2^XX. For instance here you have generated 2^41.10 = 2356854768800 keys. Yes key are incremented, but the program uses properties of elliptic to generate more keys, so the base key can also be negated (curve symmetry) or transformed via endomorphism.

[broka77]

It seems to me that there are more chances to find a collision if you randomly generate a base key once at some point in time and increment it by +1. Although the chances as you said are negligible but they are ... theoretically .. =)

[JeanLucPons]

In fact no. If you want to use the birthday paradox to find a collision you need to create a random walk, that means that you have to iterate n keys and you compare them together. That also means that you don't have an initial list of addresses to compare. In this case, having n keys into a file simply divide the probability by n.

To try to understand: If you choose one person and you compare her to n random person, the odds that you find a collision of the birthday date is simply 1-(1-1/365)^n, it is a simple Bernoulli test. Now, if you get n random persons, the probability that 2 persons share the same birthday date is much more likely. This is the occupancy problem.

[broka77]

I'm sorry, but could you implement random base key?

[JeanLucPons]

The base key is random by default, if you want to change it, just restart the program. This can be easily automated by a script. But it won't improve your odds of finding a collision. Suppose you have a blended card deck, you draw the top cards one by one and you try to find a queen. You draw 10 cards, you don't get a queen yet, do you think that reblend the remaining cards will increase your chance of finding the queen ?

https://github.com/JeanLucPons/VanitySearch#trying-to-attack-a-list-of-addresses

[SatoshiNakamotoBitcoins]

@broka77 @JeanLucPons Helpdesk Jean Luc...what a service...;-)

[JeanLucPons]

I'm sorry but I won't add something which is useless. Trust me, adding this won't give you more chance to find a collision. If you want I add it, make me a formal proof that it improves something.

You may have the feeling that changing the key improve things, but this is just a feeling. This is just because you make more test, each test are statistically independent, and changing the base key does not change the fact that each generated hash160 remains statistically independent from other generated hash160.

[broka77]

for a fee, will you make me so functional? if I can find something I’ll share with you) I just want to try my luck - try ...?

[SatoshiNakamotoBitcoins]

@broka77 That's already out there...see link below...

https://github.com/exploitagency/vanitygen-plus

But Jean Luc's app performances better!

[JeanLucPons]

If you want to increase your chance, first grab the list of the LBC project, they have a 9.000.000 address list with fund. They found very few collisions on very small private keys, probably key generated by a bad wallet but nothing since 2017-11-15. I may add, if you want, a way to set up by hand the starting key with an option ?

[SatoshiNakamotoBitcoins]

@broka77 Now is the question if Jean Luc can make here some code chocolate off it...;-)

[JeanLucPons]

and increment +1 goes to each point, as I understand it

with this approach, as I think, the chances increase

No your odds does not increase. You even loose the fact than you can exploit some failures of some bad wallets. Rather than trying to find a random collision on addresses, you should try to find collision on public key using reused addresses (there is also a lot of them) using Pollard rho random walk method, it will drastically improve your chances of finding the private key. There is even lots of thing that can be done to improve the initial Pollard's rho method. Unfortunately, I don't have much time at the moment to start such a project, but I really would like to try what can be done. I'm also working on a BIP39 mnemonic finder (not for cracking) but for helping people who loose a part (or the order) of their word list.

[SatoshiNakamotoBitcoins]

Looking forward to your Pollard rho algo Jean-Luc...

[JeanLucPons]

Satoshi himself claimed to not reuse addresses. Probably because he had the feeling that ECDLP256 can be defeated. Of course, the public key is also exposed during the transaction and if ECDLP256 can be defeated in less than few minutes, bitcoin die immediately. But what about defeating ECDLP256 in days or months ? It is strange, but I have the same feeling as Satoshi. But, in crypto a feeling is nothing, you just have to proof !