Specific Chinese Remainder Theorem crt files contributed by pdazzl

Selected crt files published by pdazzl on bitcointalk

Feb 4, 2021 • Graham Higgins ~ 2 min to read • reference

Selected crt optimisation files for shift 416, 479, 512 and 1024, as published by pdazzl

Note - values for the offset field have been broken into shorter pieces for presentational purposes, either edit them back into a single unbroken line or use the download link to retrieve an unedited version.

Shift 416

-t 8 -f 416 -i 13000 -d 6 -r crt/crt-22m-416s.txt


|== ChineseSet ==|
n_primes:     62
size:         10242
n_candidates: 765
offset:       1146441612406461563657892639195504712824084356280432767521872923

Shift 479

-t 8 -f 479 -i 13000 -d 6 -r crt/crt-22m-480s.txt


|== ChineseSet ==|
n_primes:     70
size:         11058
n_candidates: 769
offset:       1476535438052344808249114914435996661778930746178207307948586337728699041748900

Shift 512

-t 8 -f 511 -i 13000 -d 6 -r crt/crt-22m-512s.txt


|== ChineseSet ==|
  n_primes:     74
  size:         11319
  n_candidates: 766
  offset:       13367585452126639104917704816714921555816311173860045616400049444

Shift 1024

If anyone wants to go after the 1020-1024 range here is my best customized sieve file. Strange thing is Gapcoin seems to not record about 15-20% of found blocks for these much higher shifts for some reason, not sure if it’s a bug or something else. Anyways if you’re more interested in setting a bunch of new records than getting more coins and have the cpus available then this should do you well.

-t 8 -f 1021 -i 23000 -d 6 -r crt/crt-22m-1024s.txt


|== ChineseSet ==|
n_primes:     130
size:         18863
n_candidates: 1039
offset:       4626081985258152152387146716381104236401743138963348264823465389447497680671113 

Doing some more performance testing, here’s another one that appears to yield good results if someone wants to try it out.

-t 8 --shift 508 --crt crt/crt-22m-512s.txt --fermat-threads 7 --sieve-primes 10000

It’s a very low number of primes to sieve with but results in generating a LOT of candidate gaps in the gaplist. The gaplist grows by 50000 every 10 seconds. But the block percentage goes up very quickly. The reason I think it does is because of j0nn9’s algo picking the best candidate gaps from a bigger applicant pool in the heap and thus yielding block solving gaps more quickly.

You’ll want to monitor your memory usage for a couple rounds at first, the high watermark for the above arguments on my machine is about 2.6Gb of RAM so you’ll want to make sure you’re not too close to maxing out your memory.