8% here and gone.. 9% in about 14 days at current speed.

Over 3 Quintillion keys have been checked.

I just uploaded version 66.1 of the vanity client for Windows, Linux, and Vast.
Biggest new feature is sequential range mode. The client will pick a random start range and then run ranges sequentially as long as you let it run. Put seq on line 5 instead of ranges number to enable.

Put up a link to some 66 bit Pool Swag. Proceeds go towards supporting the pool. I am also planning to do a give away for some of the swag. Details will come to celebrate our 3 millionth range being checked soon. I am thinking about selecting 10 ranges at random and who ever completes those ranges will get free stuff for fun.

I'm a little late here but congrats on passing 9 percent. At current speed we should see 10% in about 7.5 days.

I have been working on client private key encryption the last week or so and am going to be slowly rolling it out to the download section. Right now I have it for Nvidia Linux and Vast configurations. Shortly after I have it working for all client versions I will faze out legacy plain text submissions. More info to follow.

The 66.2 Linux 22.04 Bitcrack client is up on the pool now with the new features. I also removed the ability to select nvidia cards since they are better off ran with vanity. Feed back is welcome as always.

10% in the books. Excellent!! 11 in about 16 days.

All clients updated to 66.2 with key encryption. Please try them. Once I feel comfortable everything is working well I will announce when the legacy clients no longer be used. I also built all gpus into the windows and the linux versions so we should not need multiple versions .

I put a real time range submission percentage of users using the updated client vs the old on the pool. I am going to make the switch required by 11%. I will send out an email tomorrow to users that might not frequent this chat. If you have already upgraded I would recommend reinstalling because I have made some tiny cosmetic changes to the clients. I think I finally have them working and looking identical between platforms.

After some discussion and feed back from the sites top 10 contributors we have decided to implement a key finder bonus. 1% of the funds from the real time active top 10 contributors will go to anyone who finds the bit 66 private key for the pool except the current top 10 at the time the key is found. Real time bonus amount is now displayed in pool.

I have updated vanitysearch in all releases to version 1.17. This biggest change is hugely improved cpu consumption. It is practically nothing now thanks to input from Andrew. I also improved cosmetics some more. Removed double printing speed and added a percentage. Woot Woot!! Reminder of the upgrade requirement by 11%.

Last reminder that in about 30,000 ranges (11%) I will be disabling legacy client support from the pool server. Normal client configs will get a server message and stop. Those of you who loop (Against my wishes) the client will continue to be doing work that will not get counted until corrected. Winning key scanning will still function.

Transistion complete and rolling out vanity 1.18. Improved key security in both high and low cpu usage for windows. Upgraded clients should reach 100 percent in less then an hour. Thanks everyone and congrats on 11 percent very shortly.

Congrats on exactly 1/8th of all ranges being checked by our pool!

I have rewritten the ttdclient in C++ for all platforms. Version 66.3 The file size is drastically smaller. This should end the annoyance of .net getting corrupted during updates. Let me know if you see any issues. Automated vast instances will load faster since it has much less to download.

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.

Client version 66.4 has been released on the pool. Main change is fixed network retry code. It was broken when I moved from c# .net to c++ in version 66.3. That was my fault. I never fully tested that feature but it is tested now. There are also a couple of minor cosmetic changes. Let me know if you have issues.

Hey everyone. We have been making great progress in the last month or so. With our DB being the most complete of any out there, the attempts to get 'fresh' ranges by nefarious entities is also increasing. Starting at 20% and on I am going to require clients to also have their bitcoin payout address be part of the line one in settings.ini so please be sure to update as soon as possible. I know it is short notice but I like to set deadlines at milestones and what better one then the big 20.

settings.ini Line 1:
Your username worker name and payout address
There should be a . between username and workername and a , between workername and payout address
workername is optional. In the case of no workername there should be a , between username and payout address
eg: Username.WorkerName,PayoutAddress
eg: Username,Payoutaddress

This does not require a client upgrade but I will be releasing a newer version to truncate the payout address when displayed in the cli to make it more visually appealing and to mask peoples addresses when screen shots are shared. So please refrain from sharing screen shots for the time being with the entire payout address being displayed with the current client software. As always feel free to reach out if you have any questions.

Just a reminder that sometime in the next 24 hours we will be crossing the 20% complete milestone and settings.ini files will need to be edited to now include the payout address from your accounts to better secure the server from abuse. See previous announcement for more details.

update complete be sure to update in order for it to continue working