Vanitysearch bugs

[a8832021]

When I use vanitysearch to scan test pool 38 ,it can't stop when finish a range. And it can't drop a file when it find the target address or a pool reward.

[ilkerccom]

Hello. Thank you for feedback.

Yes vanitysearch test pool 38 is running quite slow. However, I did a lot of testing and could not see any problems in finding the key.

It even finds the key while searching for range 18. (Correct range 22) It cannot finish the scan immediately.

If the private key is found, it writes it to the console and creates a txt file in the directory where the application is run. (untrusted_computer value must be false)

Additionally, if you are using a previously built vanitysearch, the application will not be able to find the key. The “vanitysearch” fork in my repo should be used.

Could you test it again and share the result?

Thanks.

[a8832021]

Also I don't know how to set "app_arguments=" when use vanitysearch so I just delete it.

[a8832021]

I found something more interesting,when I chose to scan range 20,if I wait for several minutes, it can find the target key at range 22.I guess it may have many startpoints, so it may scan both keys in the range and in the ranges after it due to the narrow space.But in puzzle 66, one range contains about 1.1T keys so the problem becomes negligible. Plus when I test the pool 38 ,if a range isn't scanned in 2 minutes ,it won't be scanned by others.When I test scanning range 21 twice with a spare time more than 2 minutes ,the app just prints " Reached of keyspace. No ranges left to scan." May it happen in the formal pool? I know many ranges may be assinged but not finished for many reasons. So I think it is necessary to check this bug.

[ilkerccom]

Also I don't know how to set "app_arguments=" when use vanitysearch so I just delete it.

This enough for vanitysearch.

I found something more interesting,when I chose to scan range 20,if I wait for several minutes, it can find the target key at range 22.I guess it may have many startpoints, so it may scan both keys in the range and in the ranges after it due to the narrow space.But in puzzle 66, one range contains about 1.1T keys so the problem becomes negligible. Plus when I test the pool 38 ,if a range isn't scanned in 2 minutes ,it won't be scanned by others.When I test scanning range 21 twice with a spare time more than 2 minutes ,the app just prints " Reached of keyspace. No ranges left to scan." May it happen in the formal pool? I know many ranges may be assinged but not finished for many reasons. So I think it is necessary to check this bug.

Yes, as I mentioned before, since the scanning process is not finished, it finds the private key in the next ranges. Since there is no such problem in the real pool, I did not pay much attention to it. However, I think the same problem will occur again when running 16 4090s. Because there is a problem when there is too much power in a narrow space. :)

Thanks.

[a8832021]

Also I don't know how to set "app_arguments=" when use vanitysearch so I just delete it.

This enough for vanitysearch.

I found something more interesting,when I chose to scan range 20,if I wait for several minutes, it can find the target key at range 22.I guess it may have many startpoints, so it may scan both keys in the range and in the ranges after it due to the narrow space.But in puzzle 66, one range contains about 1.1T keys so the problem becomes negligible. Plus when I test the pool 38 ,if a range isn't scanned in 2 minutes ,it won't be scanned by others.When I test scanning range 21 twice with a spare time more than 2 minutes ,the app just prints " Reached of keyspace. No ranges left to scan." May it happen in the formal pool? I know many ranges may be assinged but not finished for many reasons. So I think it is necessary to check this bug.

Yes, as I mentioned before, since the scanning process is not finished, it finds the private key in the next ranges. Since there is no such problem in the real pool, I did not pay much attention to it. However, I think the same problem will occur again when running 16 4090s. Because there is a problem when there is too much power in a narrow space. :)

Thanks.

I found this problem happen when I use 2 RTX3080 cards. It takes about 20 seconds longer than expected. So I suggest not use more than one card together in order to make the most of computing power. For example, if you have 2 cards, you can copy the software fold and set each setting file to use GPU0 and GPU1, then open these two software, each software will only use the GPU assigned respectively. Thanks.

[ilkerccom]

I don't think it's related to multiple graphics cards.

Because I have a single 3090 and it takes about 1 minute for the scan to finish and the range to be marked (pool 38). With Bitcrack this only takes a few seconds. The more you increase the power for a narrow area, the longer it takes to scan.

However, since there is no such problem in Puzzle 66 and others, it is not a major problem at the moment. This may be a problem for other puzzles with 8x 5090. Because a single 4090 completes a range in 4.4 minutes. When we increase this to 8, a range scan is scanned every 30 seconds. However, currently this may take 40-50 seconds. If a better version of vanitysearch is found, this problem will go away.

Thanks for your feedback and testing.

[thewhitegrizzli]

nobody cares Laurent

On Fri, Apr 5, 2024 at 3:48 AM ILKERC @.***> wrote:

Closed #37 https://github.com/ilkerccom/bitcrackrandomiser/issues/37 as completed.

— Reply to this email directly, view it on GitHub https://github.com/ilkerccom/bitcrackrandomiser/issues/37#event-12369513962, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACBZKLE76GYUTA32DR6O2IDY3ZJNBAVCNFSM6AAAAABE5U2FEKVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJSGM3DSNJRGM4TMMQ . You are receiving this because you are subscribed to this thread.Message ID: @.*** com>