Although the list does not look impressive, much was accomplished in 2017. The sub-searches that were completed were some of the longest so far. In summary:
1. The search over Q(sqrt(2)) (subfield 3 of 7) completed several more tiers of the search. There are about 9 tiers left to go.
2. The search over Q(sqrt(-2)) (subfield 4 of 7) filled in a bunch more rows. This one has 7 tiers left to go.

Here are the goals for the new year:
1. Develop a GPU app. I have enlisted the help of a fellow user for this. This is a lofty goal and it could be many months before the GPU app is available. This app will be critical in completing the search over Q(sqrt(2)).
2. Complete the search over Q(sqrt(-2)).
3. Start the search over Q(sqrt(-5)) (subfield 5 of 7).

You will notice that all those errors are "download errors". As Richard mentioned above this means the file does not exist anymore on the server. I also checked a few of these, and the server has the data, which means it got returned at some point. My best theory as to what happened is that while the database was crashing (which could have been over a period of hours), these results got returned, validated, assimilated, and then marked for deletion. The file_deleter did its job and deleted the file. During restoration of the database, some wus/results got put back to an earlier state. So the server is resending these results but the corresponding data file has already been deleted.

Also note that the server has to go through 8 of these download errors before it gets flagged as bad and then subsequently removed from the queue. I would reduce the 8 if I could, but it's part of the WU template which means the value is already set in the database.

I hope that helps explain things.

Also, I was able to fix the create_work script, so new work is being generated.

I just discovered something else... although all the project daemons are working as expected, the create_work script cannot connect to the database, so it looks like we missed something when reinstalling mysql.

So just a heads up, we may run out of work until I get this fixed.

I don't do double checking because that would mean the project would have to wait twice as long to complete a search. The most likely reason for someone returning a faulty result would be deliberate maliciousness; do you know of any studies that show what percentage of users do that? Most of the "cheaters" find ways to artificially increase their FLOPS and/or compute time (like running many VMs in parallel) without compromising the results themselves.

With that said, my combiner scripts have checks in place to flag suspicious results. It has flagged numerous results, which I then run again, but so far none of these have been fallacious.

Also, the algorithm itself has some built in redundancy in the sense that it finds about 100 times as many polynomial representatives as there are actual fields. The theorems that the algorithm uses guarantee that there exist polynomial representatives within certain coefficient bounds, these bounds are sufficiently large that it picks up the field 100 times (on average). As a side note, finding tighter bounds would be one way to speed up the algorithm, as this would reduce the search space.

In addition to all that, once a search is complete, there are relationships between the numbers of fields of various Galois groups. This would most likely detect a missing field. For example, the number of decic fields with Galois group 10T17 must be even. But like a parity bit, the check can fail if there are multiple errors.