Quote from: simplebtcfuture on Today at 05:25:14 PM

Quote from: zielar on Today at 01:09:03 PM

As you can see on the ttdsales.com/64bit/ pool, which is actively working to find the key to # 64 - apart from me, there is also a group of people who with little power, but still support the search, because each already proven range falls out of the pool of possibilities, and what a hence -> the number of possible ranges is constantly decreasing

yes I have been lurking around that pool for a while and up to date for the most part, I just never owned a gpu and would like to throw one or two at the pool for fun. 3 questions:

1) Would it be a bad idea to purchase a used gpu? risky efficiency/speed wise?

2) Do participants get to choose which specific range they would like to allocate their gpu's to on ttdsales?

3) Are the already scanned ranges publicly published somewhere?

thank you for your answer

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:

Code:

zielar
-gpu -gpuId 0,1,2 -t 0
0xC000000
0xFFFFFFF
16

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: P