You want this code: https://github.com/bitcoin-core/secp256k1/pull/507 it will be astronomically faster than your current code.
I believe when I previously implemented the techniques in this code my result was faster than vanitygen on a GPU.
I believe when I previously implemented the techniques in this code my result was faster than vanitygen on a GPU.
Thank you. Yes, I want that code! I will promptly set this as a priority feature; I can’t wait to measure the speedup. secp256k1 already beat OpenSSL about 7x when I tried them head-to-head in my same code; looking at the description in the code, I am guessing that “astronomically” will mean “orders of magnitude”.
FWIW, the code checked into the tree is copied from Bitcoin Core v0.15.1. I intended to mention that in my commit log, but forgot. Of course, I follow the secp256k1 repository; but I know it does not yet have any releases, and I wanted to be just a tiny bit conservative when using software I know is marked experimental.
It could also be made faster still with some improvements. E.g. it doesn't actually need to compute the y coordinate of the points, so several field multiplications could be avoided in the gej_to_ge batch conversion. It could also avoid computing the scalar for any given point unless you found a match. (E.g. by splitting the scalar construction part into another function which you don't bother calling unless there is a match).
Another advantage of this code is that it is setup to allow an arbitrary base point. This means you could use untrusted computers to search for you.
Another advantage of this code is that it is setup to allow an arbitrary base point. This means you could use untrusted computers to search for you.
Excellent. I see it. That may call for going back to the drawing board, and performing some daemonology. I’ll see what ideas I can cook up for a client/server generator. It may be be a higher priority than full Windows port, if I can work out an easy way for Windows-only users to submit their requests to a “cloud” machine and then do the tweak multiplication on their own machines.
Sipa also has AVX2 8-way sha2 and ripemd160 that he might post somewhere if you asked. An 8-way bech32 checksum generator should be really easy to do,
Will ask. Actually, I think I may have this mentioned somewhere in GH discussions; I didn’t pay attention, because I don’t yet own any machines with AVX2. Not quite as rich as people think I am.
I myself will not try implementing such things, even the “really easy” ones. I don’t have the CS background. After tinkering for years, I learned programming by reading FreeBSD kernel code until I thoroughly understood almost everything except the CS-heavy subsystems (vm, scheduler, etc.). I think you see that my code reflects the style you’d expect from that experience. Otherwise, as in all else, I take pride in knowing enough to know the limits of my own knowledge.
though if your expression doesn't match on the final 6 characters you should avoid even running the checksum.
Of course. Avoiding unnecessary checksums is an easy optimization all around, though it will require some refactoring to open up a code path for that. Also, I want to at least optionally support expressions such as 'qqqqqq$'. I’ve had fun generating a few neat addresses that way.
Time to go code...
