After some discussion with Louie Helm at Seventeen or Bust, we are going to change the way work is divided between SoB and PG. After a transition period, PrimeGrid will be crunching only k=10223 and k=67607, while SoB will crunch only the other 4 k's. Each project will be entirely responsible for its own k's.
Why? Well, if we never find another SoB prime, things will work fine the way are now. But if we take a more optimistic view and assume we WILL find a prime, there's a problem: We'll have wasted an immense amount of crunching. This change will correct that problem.
Currently, PrimeGrid is crunching in the n=27M range, and SoB is crunching in the 29M range. If PrimeGrid finds a prime in the 27M range, every test that SoB did in the 28M and 29M ranges in that k will have been wasted effort! Likewise, once we finish the 27M tests and move on to 31M tests, if SoB finds a prime, everything PrimeGrid will have tested at 31M in that k will have been wasted.
By dividing the work by k we avoid this problem.
One thing that doesn't change: if PrimeGrid finds a prime, both PG and SoB share the project credit for the discovery.
The current plan is for us to complete the current 27M and upcoming 31M tests in all the k's and then only crunch 10223 and 67607. At some point we will probably do some double checking of earlier SoB work that was not yet double checked. Details will become available later.
(For those that are curious and more attuned to the details, the residues that SoB uses are not the same as what PrimeGrid normally uses. This makes double checks more complicated. However, our LLR program can do the same test and produce the same residue as SoB's software if we use the correct command line arguments. However, SoB's older software has completely incompatible residues, so hopefully there aren't a lot of those that need double checking.)
My lucky number is 75898524288+1