For example:
If you get the range 20000000000000000-2000000ffffffffff and the address generated by the pool is 12RBvs1P9D2oD8Bk3MtfYCJ71KmDiLHLZq(privkey:200000096a7342abc). You can submit the work immediately once you reach the privkey of it and not scan the keys after that. Then get another job.
If you get the range 20000000000000000-2000000ffffffffff and the address generated by the pool is 12RBvs1P9D2oD8Bk3MtfYCJ71KmDiLHLZq(privkey:200000096a7342abc). You can submit the work immediately once you reach the privkey of it and not scan the keys after that. Then get another job.
Do you mean this announcement from Telegram ttdsales #66
----
I have been doing a deep dive into the range submissions from the user kafeitianshi. He ran very hard for a couple of months but I have never been in communication with him. There was a vulnerability in the system that would allow a user to kill either vanitysearch or clbitcrack right after the PoW key was found then the client would submit for credit, restart, and continue. It seems this is how all of kafeitianshi work was submitted. I was able to determine this by looking at the times between when a range was requested and when it was submitted. Under normal operation this would conform to standard deviation. In this users case the time taken between ranges was just as random as the location of the PoW keys in the respective ranges.
This vulnerability has been eradicated in the newer clients.
So the bad news is that I need to mark the 227,357 ranges as unchecked and we take a 0.67% step backwards in overall completion.
The good news is that the ranges scanned on the pool are more accurate then ever.
I will continue to investigate range submissions for any other anomalies.
In my opinion,the best solution for this problem is to work in a solo-pool such as btcpuzzle.info and play it as a lottory. Because you are working for yourself so such attack methods is meaningless.
