A possible attack method for btc puzzle pool: ttd's pool.

[a8832021]

The BTC puzzle is to find the privkey in a certain range for an address. And I found that some people solve this problem just like mining BTC. Such as the pool ttdsales/66bit/login.php. I found that the pool probably generate a random address and you should submit something relevant to the privkey of the address as a proof of work. And the pool client is not open-source. I think maybe someone cracked the software and submit the answer once the privkey of the random address is found. So if the solution is found,the hacker may gain more reward than usual. And it may cause the pool can't find the solution.

[jacky19790729]

The BTC puzzle is to find the privkey in a certain range for an address. And I found that some people solve this problem just like mining BTC. Such as the pool ttdsales/66bit/login.php. I found that the pool probably generate a random address and you should submit something relevant to the privkey of the address as a proof of work. And the pool client is not open-source. I think maybe someone cracked the software and submit the answer once the privkey of the random address is found. So if the solution is found,the hacker may gain more reward than usual. And it may cause the pool can't find the solution.

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
 

[a8832021]

The BTC puzzle is to find the privkey in a certain range for an address. And I found that some people solve this problem just like mining BTC. Such as the pool ttdsales/66bit/login.php. I found that the pool probably generate a random address and you should submit something relevant to the privkey of the address as a proof of work. And the pool client is not open-source. I think maybe someone cracked the software and submit the answer once the privkey of the random address is found. So if the solution is found,the hacker may gain more reward than usual. And it may cause the pool can't find the solution.

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.

[jacky19790729]

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.

[a8832021]

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.