Vanitygen - technical discussions

Let’s talk here about the future of vanitygen. :slight_smile:

A proposition of vanitous logo :

vanitygen-min

4 J'aimes

Nice! :slight_smile:

from
https://forum.monnaie-libre.fr/t/does-vanitygen-accept-contributions/14327/17

I assume Tikka is a wallet. (I only heard of Sakia and Silkaj.) It might be simpler to keep vanitygen as a separate program and have Tikka retrieve the output securely. vanitygen is something I leave running overnight with multiple rules loaded.

If that’s a suggestion to rewrite in Rust, there is a lot of code to go through. I would prefer Ada if I knew more about using libsodium and OpenCL. (There are available bindings for both, and Ada is a much more mature language for secure / mission-critical programming.)

I suggested Rust, but any language able to compile shared libraries usable in Rust, Python, Javascript (Wasm) easily will do. I do not know ADA.

Tikka is a Python/Tk client to manage accounts. Sure, if VanityGen is a long and costly operation for the computer, it better be completely separate.

if ((positLastLF < posit - 1) && (buf[positLastLF + 1] != '\t'))
    	nbregexlines++;
positLastLF = posit;

The loop containing those statements appears to be counting the number of lines. Is there a reason why lines starting with tab characters are ignored?

Indeed, it was an undocumented dirty trick to ignore those lines to quickly try out different regex in the same file without losing them or having to create another file. :slight_smile: I even forgot about that feature. :smiley:

I moved the block for regexes from main to its own function and updated documentation for changes to arguments. Would you consider merging my branch?

1 J'aime

Yes sure. Why don’t you create an account on the Duniter git? It would be simpler.

I tried to earlier, but it requires approval from administration (which hasn’t happened).

Not sure who is the admin there… @elois @Inso ? :slight_smile:

The git repository I’ve been tracking for vanitygen was the github one. I didn’t know there was a git.Duniter one as well. After my branch gets merged, I’d like to touch up the English readme. I think usage in -h could also be more concise.

What are your thoughts on removing pasted functions and including libsodium (adding the dependency)?

Actually I’ve mislead you… it was not on the git.duniter.org site, it was on my own gitlab. Let’s trash gitlab and github and switch to git.duniter.org, it makes more sense for it to be there anyway.

@administrateurs anyone could accept @scuti 's account on the duniter git?

3 J'aimes

Of course it sounds neater. My problem is that libsodium is big and we actually need just a fraction of what it contains.

Besides, is it possible to include libsodium directly if we build an opencl version or does it need some tweaks? I made the assumption that switching to opencl would require tweaks and/or isolating only the parts we need because the smaller code you run on a GPU, the better. This is why I did the copy/paste in the first place.

In precise terms, do you mean the size of the binary should be as small as possible?

Also RE: Gitlab/Github, I’m using gitea on Teknik. I see your new repository has my branch. Could you also fetch master then merge the two branches? (If you think it’s fit for a merge.)

It’s incredible GCC links dead code by default! Rust doesn’t… Anyway there seems to be options to remove dead code at link time with GCC.

I’ve implemented random private key seed match with regex in Ğ1force, on 4-core i5-7300HQ it tests up to 177000 seed/s.

https://git.teknik.io/scuti/vanitygen/src/branch/libsodium

If he meant to reduce the size of the binary for GPUs, I’ve made a branch where I’ve included libsodium. Including libsodium and commenting some of the pasted code reduced the file size from 145 kB down to 105 kB.

1 J'aime

@tuxmain As @scuti mentionned, the initial goal was to make an opencl version. GCC does link only what is needs. :slight_smile: It compiles much faster with the lib, by the way (with downsides, read on!). How fast is vanitygen on your i5? (just clone https://gitlab.com/jytou/vanitygen/, make, create a regex.txt file with for instance ^aaa as a single line and launch ./vanitygen -s regex.txt, that’s it, no dependencies needed)

@scuti The main problem for me is that lsodium might not be available everywhere easily. Now I remember why I didn’t want to link libsodium in the first place. Just FYI you have broken the compilation on my raspberry pi, for instance (yeah, it runs at a ridiculous 6500 seeds/s, so what? I just need 30 of them to compete with tux’s i5 :stuck_out_tongue: ). And I was also using Solaris machines at the time when I developed this… with my simple copy/paste, no need to install anything. Just clone the git and compile, done. Installing libsodium can be a serious pain in some environments (and in the worst case you have to compile the whole thing).

Another side effect is that the performance drops dramatically when compiling from lsodium. With my copy/paste version, I am running at 500 keys/s (not seeds), but with lsodium I run at 300. I guess the -O3 in the gcc args is the reason.

So for the time being I would certainly not be favorable to the whole libsodium-linking change.


@scuti it seems that the basic functionality of running vanitygen is broken after your changes on the command line. I get:

$ ./vanitygen regex.txt 
Exiting: no regex file specified.$ 

Actually, after peeking for a second at your code, you have changed the command line arguments, which is not good for compatibility. I would really like it to be as it was: the regex file is the only mandatory thing and shouldn’t need a switch.

And I also can’t run seeds:

$ ./vanitygen -s -x regex.txt 
error: s arg is NULL
Initialization failed.
$

Is your account on git.duniter.org not approved yet? @administrateurs

I have pushed my main branch on https://git.duniter.org/jytou/vanitygen/-/tree/master

@scuti your changes are in the branch https://git.duniter.org/jytou/vanitygen/-/tree/scuti/refactor/

I don’t understand the problem between libsodium and OpenCL.

Compilation time and executable size are impressive (Rust is very slow to compile and executables are big), but it runs at 100000 seed/s with 4 threads.