Potential attack strategy for btc puzzle pool: ttd's pool.

So the BTC puzzle is all about figuring out the privkey within a specific range for an address. I noticed that some folks tackle this like they do with BTC mining. For instance, there's this pool called ttdsales/66bit/login.php. It seems like the pool generates random addresses, and to prove your work, you need to submit something that relates to the privkey of that address. The pool’s client isn’t open-source, which makes me think someone could’ve hacked the software and submitted the right answer once they found the privkey of a random address. If that happens, the hacker could potentially snag more rewards than usual, which might mess up the pool’s ability to find solutions.

Only the puzzle creator knows the private key #66 and can do this, but I don't think he would be so boring to do it

You don't need to know the answer. You will get a range which contains 2^40 keys,which contains a address generated by the pool,and probably not contains the answer of the puzzle. I means the pool will pay the reward to each one by the ranges count they scanned. If you submit your work once the privkey of the address generated by the pool is found and don't scan the keys behind,you may get more reward. 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.

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.

Even though you update the client, the problem can't be solved thoroughly due to the vulnerable mechanism. But there are some methods to detect fake submission such as looking at the times between when a range was requested and when it was submitted. If it is relevant to the random key position it is probably fake submission.Also you can add more random keys for proof. But maybe the attacker may grasp the package and if the solution is found, he or she may broadcast the transaction and send the reward to his or her address. 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.