Topic: VanitySearch (Yet another address prefix finder) - page 48. (Read 32966 times)

That is inexcusably small, and adding a PID to it wouldn't make it meaningfully better.

Strengthening can be a useful tool in the rare case where there isn't any alternative, but it doesn't replace having good entropy to begin with. The only systems that should use weak entropy (plus strengthening) are ones where the unrelated-to-you brute force attackers shouldn't exist (e.g. where they need a secret database to even begin the attack) and where there can be a strong nonce to prevent parallel attack speedups and precomputation.

Every operating system offers a source of cryptographically strong random numbers. Why isn't it using 256-bits (or at least 128 bits) of OS provided entropy?

The default seed has an entropy of ~48bit (if you manage to guess the date of the address creation), so to guess a key generated by the default seed used by VanitySearch, you need to execute ~2^48 pbkdf2_hmac_sha512 and to run  ~2^48 times the search up to the desired prefix. I let you do the calculation of the necessary power to compute an address in a feasible time when you know the day of an address creation
But ok, I will modify the code and add the PID, it will add 16 more bits to the default seed entropy.

There are 2 ways to generate safe addresses:

1) Use a strong seed.
2) Use a split key (-sp) with a public key generated by a third party software (In that case, VanitySearch cannot suffer from any vulnerability)

Yes if you don't use a seed, for very short prefix. But it will still require lot's of power.
Again, I recommend to use a strong password (-s option) to generate safe base key.

The way pbkdf2_hmac_sha512 is implemented is safe, long passwords (>128 characters for SHA512) are truncated to 128.
No change needed here unless someone finds a trap of really wants password longer than 128 char.


Hi,
Yes it could be done but I still have work with fast base58 encoding and I will be off the next week.

Why do you want to implement in a different way ?

and ?
did you manage to exploit something ?

You can use Wallet->Private keys>Import to import address(es) (giving the corresponding private key(s)) in the current opened wallet.
I'm using Electrum 3.3.4.

Thanks to all for these performance reports. I appreciate it
Note that the Tesla V100 result was with an old release.
If i compare to the result of the 1080 ti  posted in the same SlarkBoy's post, 1255M/Ks for 2 1080Ti, (627MK/s per board), and the result from here (1001 MK/s) we may expect a 60% speed increase on the Tesla with last VanitySearch release (~2800MK/s).

Exact OgNasty the RTX 2070 is the best performance / price compromise .... just look at the TESLA V100 $ 10000 scores for 50% extra speed or a 2080 TI twice as expensive as a 2070 but for a result that is not doubled in terms of speed ... if in addition we take into account the power consumption the RTX 2070 is very correct

this setup worked
perhaps  you should make it as a default setting

this is the code I added to the shortcut to the program, as you pointed. It worked perfectly.

edit:
also, Is it possible to add this address to a specific electrum wallet? I don't think it's possible without creating a new wallet, correct?

I underclock my cards so I'm not sure I should post the speeds, but I can say that the 2070 outperforms the 1080ti and even the liquid cooled model by a little bit, and uses significantly less power while doing so.  The 2070 is a great buy for this purpose in my opinion.

1) added
2) Amazon. The source of all things: https://amzn.to/2Li0UsI

-Dave

Thank you very very much! I am really looking forward to a new commit.

GPU: GPU #0 GeForce GTX 750 (4x128 cores) Grid(32x128)
104.960 MK/s (GPU 94.405 MK/s) (2^32.12)

Oh my take my money I want buy that now

Bonjour
You can add it https://bitcointalksearch.org/topic/m.50108268

Many thanks for your report Dave

Some news:
Wildcard search is between 4 and 5 times slower than classic search for known prefixes. I reach ~40MK/s with my 1050 Ti and ~4MK/s with my i7-4770.
It is due to the fact that I have to compute full address each time and it requires 2 SHA for the checksum and a base58 encoding. For the CPU release, I implemented SSE checksum and I will try to implement SSE Base58 encoding using Barret's reduction (for computing div and mod 58).

I updated my original post.
https://bitcointalksearch.org/topic/m.50823897

I am going to do my best to keep it updated as more info comes in.
As I add cards I will post the date added so there will be some form of tracking.

-Dave

GPU: GPU #0 GeForce GTX 1060 3GB (9x128 cores) Grid(72x128)
321.929 MK/s (GPU 321.929 MK/s)

Hi Jean_Luc,

Thank you for your work. It's a huge step for generating vanity addresses. I appreciate it.

Has anyone put together (or started to put together) a list of CPUs / Video Cards & the speed you can get out of them.
I know it's a newer project and Jean_Luc is working VERY VERY hard on it so getting accurate numbers is going to be a moving target. But for now all we can do is look through the thread and see who is running what to get a general idea.
So far I have pulled from this thread:

GPU: GPU #0 GeForce GTX 1080 Ti (28x128 cores) Grid(224x128)
914.418 MK/s (GPU 896.216 MK/s)

GPU: GPU #0 GeForce GTX 1050 Ti (6x128 cores) Grid(48x128)
220.180 MK/s (GPU 220.180 MK/s)

GPU: GPU #0 GeForce GT 520M (1x48 cores) Grid(8x128)
10.233 MK/s (GPU 7.026 MK/s)

GPU: GPU #0 GeForce RTX 2070 (36x64 cores) Grid(288x128)
1535.880 MK/s (GPU 1470.257 MK/s)

Added 30-April-2019

GPU: GPU #0 GeForce GTX 1060 3GB (9x128 cores) Grid(72x128)
321.929 MK/s (GPU 321.929 MK/s)

GPU: GPU #0 GeForce GTX 1080 (20x128 cores) Grid(160x128)
672.062 MK/s (GPU 672.062 MK/s)

Added 1-May-2019

GPU: GPU #0 Tesla V100-SXM2-16GB (80x64 cores) Grid(640x128)
GPU: GPU #3 Tesla V100-SXM2-16GB (80x64 cores) Grid(640x128)
GPU: GPU #2 Tesla V100-SXM2-16GB (80x64 cores) Grid(640x128)
GPU: GPU #1 Tesla V100-SXM2-16GB (80x64 cores) Grid(640x128)
7260.449 MK/s (GPU 7212.931 MK/s)
So 7260 / 4 = 1815 MK/s

GPU: GPU #0 GeForce GTX 750 (4x128 cores) Grid(32x128)
104.960 MK/s (GPU 94.405 MK/s) (2^32.12)

Added 3-May-2019
i7-7700K CPU Number of CPU thread: 8
22.092 MK/s (GPU 0.000 MK/s)

With -t 7
Number of CPU thread: 7
21.609 MK/s

Added 8-May-2019

EVGA RTX 2080 XC ULTRA
1427.967 MK/s (GPU 1424.946 MK/s)

Added 23-May-2019

GPU: GPU #0 GeForce GTX 1660 Ti
961.319 MK/s (GPU 961.319 MK/s)

GPU: GPU #0 GeForce RTX 2080 Ti (68x64 cores) Grid(544x128)
GPU: GPU #1 GeForce RTX 2080 Ti (68x64 cores) Grid(544x128)
5128.213 MK/s (GPU 5128.213 MK/s)
So 5128 / 2  = 2564 MK/s


Added 8-June-2019

GPU: GPU #0 GeForce GTX 960M (5x128 cores) Grid(40x128)
117.802 MK/s (GPU 117.802 MK/s)

Added 23-July-2019

GPU: GPU #0 GeForce GTX 1660 (22x64 cores) Grid(176x128)
839.061 MK/s (GPU 839.061 MK/s)

Added 25-July-2019

GPU: GPU #0 GeForce GTX 1650 (14x64 cores) Grid(112x128)
511.906 MK/s (GPU 511.906 MK/s) (2^36.97)


Added 21-Nov-2019

GPU: GPU #0 GeForce GTX 970 (13x128 cores) Grid(104x128)
360.322 MK/s (GPU 331.442 MK/s) (2^32.77)

Added 25-Nov-2019

GPU: GPU #0 GeForce GTX 980 (16x128 cores) Grid(128x128)
375.384 MK/s (GPU 375.384 MK/s)

GPU: GPU #0 GeForce RTX 2060 SUPER (34x64 cores) Grid(272x256)
[1361.71 Mkey/s][GPU 1361.71 Mkey/s]

GPU: GPU #0 GeForce RTX 2080 SUPER (48x64 cores) Grid(384x256)
[2001.52 Mkey/s][GPU 2001.52 Mkey/s]

Anything else?

-Dave

Last updated 25-Nov-2019.

Thanks for the link, I will have a look at this.
Adding a way to generate only upper or lower case is easy except for the difficulty calculation.


Thanks for the info but as written in the readme it is better to use a seed for generating a safe base key and obviously to run it on a machine where you are alone. The PNRG is not used at all by default, it is enabled only if you want to use the -r option which I do not recommend (I will add a UNSAFE message in the command line usage infos for the - r option).