VanitySearch benchmarks

https://bt.irlbtc.com/view/5112311.msg50823897#msg50823897

However, the speed using ttd version will be slower since it is searching for keys in one specific range versus original vanity search that searches using inversions and such.

1) Not a bad idea. This has no effect on performance. When buying a used one, it is worth knowing what the card was used for during its use (i.e. whether it was used as a graphics card in the computer or used for crypto mining). the same new.
2) The participants can decide on their own to what extent the parties they want to be allocated. For example - the VanitySearch configuration file consists of five lines, as in the example on my one machine:

which in turn means for the program: 1. my login 2. commands for vanitysearch for selected processors 0,1,2 and excluding CPU usage, 3. Lowest selected range, 4. Maximum selected range, 5. Number of simultaneously downloaded ranges (i.e. I download 16 ranges at once to eliminate connecting to the pool every single range)
3) The specific scanned ranges are not published for obvious reasons which, apart from their huge number, include issues that eliminate the support of people not participating in the pool. Working for a pool is about bringing their members closer to the correct key, not letting outsiders know which ranges are already checked and empty. Thanks to this also - the pool has an advantage over people who will try their luck [in the form of already such a large resource of proven ranges], and as a colleague wrote earlier - the full range is huge. This 16% consists of more than 21 million sub-ranges that the Pool has already scanned, while the full sub-range pool is 134,217,728.

However, you can see the estimated distribution of the scanned sub-ranges in the table after logging in, divided into 16 parts - from which you can see, for example, that the final (F80000-FFFFFF) range is already scanned in 45%, while the initial (80000-87FFFF) only in 4%. This information, however, is so useless for outsiders, because the correct key is only one and it can still lie in the still unchecked part of the last range, while the very percentage discrepancy from the beginning to the end results from the fact that I insisted on the second half of the range and as I wished, the system assigned me sub-ranges from the second half to be scanned.

P.S. As a curiosity, I will only mention that today I switched to the initial ranges, because my whim regarding the sub-ranges has changed

---

Thanks a lot. This is what I was looking for. This will be very helpful, as these results were created while the VanitySearch performance was the same as the current VanitySearch performance with the scoping option. Nevertheless - the values will be more or less very similar, and I have a base for possible development. Soon there will be a table in the main topic - which I will gladly supplement with the missing types of cards, if someone has one ... Then I ask for info in the post or in PW (i.e. what GPU, how many Mkeys s achieves and any additional starting variables such such as -g which increase performance)

[EDIT]
I've already added the performance sections to the main topic.

I wish I had saved my 115 files. I didn't think they would ever be useful then, and their size didn't encourage me to keep them anyway. Well ... it's hard. If I still have time - I will definitely join the cooperation, but I promised myself that I would finish topic # 64 for good first, and then focus on Kangaroo. In any case, if I get it again - we will surely get along somehow, because I will be happy to join the cooperation again, rather than wanting something again myself.

Can you clarify this number?
You wrote 1,4 billion but used Mk/s (million keys per second).

Is this 1,4 billion keys per second or what?

Ok, that's 1,4 billion k/s.
Makes sense.

probably not going to be the code that finds it, but i notice people have posted python here so..

https://github.com/barrystyle/b58

is currently hardcoded for #64,
on my 11th gen i7-1165g7 manages around 124,000 keys/sec.
matches using the hash160 rather than the full base58 address for speed.

james

and? this doesnt prevent you from running it,
although it does suggest you should try a compiler thats a bit more recent that 2015 

I have returned EVGA cards (what I mainly try to buy, they are better IMO, especially cooling) and have never had an issue. I do not know what the cards were used for prior to me receiving them (used cards) but I know I have tweaked the clocks and power settings (for performance). I've had a few 2080Tis and 2070 Supers that would start working and run for a few minutes (whether mining or another program like Kangaroo) and they would return various errors. In the RMA process, I put the exact error or code into the form. I've never been asked nor denied an RMA. Only thing I have read is physical damage...I do not think they would cover that. I am sure every manufacturer is different.

This was mentioned before somewhere. Can't remember where. But from what I recall.... If you don't cheap out on the Tx Fee you will be fine. Because once it's seen on the blockchain the double spend protection will kick in. Bad wording so to the experts I apologize. But it's unlikely you will not receive it should you have the private key.