Chinese Remainder Theorem Mining

Mining with shift >= 64 using the Chinese Remainder Theorem

The speed of mining with higher shifts (64 and above) can be improved by using the Chinese Reminder Theorem (CRT). The higher the shift (up to 1024), the better the improvement from using the CRT - but with higher shifts the mining speed also decreases. However, if you are aiming for shifts 64 and above anyway, then using the CRT will make a positive difference.

Fast track copy’n’pasta

Get-you-started crt mining params: shift 64, 4 threads (1@gap scanning, 3@fermat sieving), sieve-primes of 13000.

gapminer localhost -p 31397 -u <user> -x <password> -t 4 -d 3 -f 64 -i 13000 -r crt-22m-64s.txt


When using GapMiner with the Chinese Remainder Theorem for mining, in addition to the standard GapMiner parameters --threads, --sieve-primes and --sieve-size, there are two additional mining parameters that must be set appropriately: --crt and --fermat-threads.

      -r  --crt               use the given Chinese Remainder Theorem file
      -d  --fermat-threads    number of fermat threads when using the crt

Although --sieve-size remains settable, it is not used when mining with the Chinese Remainder Theorem.

-r --crt

use the given Chinese Remainder Theorem file

Using GapMiner with the Chinese Remainder Theorem requires the choice of a CRT file, containing search values optimized for a specific shift, starting at 64 (i.e. searching primes of 97 digits in length).

As originally distributed, crt files for the following shifts were made available in the GapMiner repository: 64, 96, 128, 160, 192, 224, 256, 288, 320, 352, 384, 416, 448, 480, 512, 544, 576, 608, 640, 672, 704, 736, 768, 800, 832, 864, 896, 928, 992, 1024.

The shift setting doesn‘t have to match the crt shift, you can mine with --shift 510 using the crt file crt-22m-512s.txt.

-d --fermat-threads

number of fermat threads when using the crt

Mining with the CRT is split into sieve and primality testing, using separate threads for each:

--threads 4 --fermat-threads 1

The above example is parsed by the Gapcoin miner as: use 3 threads for sieving and 1 thread for gap scanning.

Using GapMiner with CRT requires at least two threads.

The scan threads always pick the most promising gap from the gaplist (the gaplist is implemented as an heap), therefore the gaplist value should always be at least over 100. Altering the gaplist size can be achieved by altering --sieve-primes, --threads or --fermat-threads.

Having a gaplist with too high a value (e.g. over 9000) can slow down mining.

Recommendations derived from practice and testing

  • set --fermat-threads = --threads minus 3 for shifts below 128.
  • set --fermat-threads = --threads minus 2 for shifts above 128.
  • set --sieve-primes for optimal block% (probably close or below).

If you want more --fermat-threads then the value of --sieve-primes needs to be reduced and vice versa.

Fine-tune the sieve-primes value by only adjusting 1000 at a time then running for a minute to observe. The ideal behavior is for the gaplist size generally (most of the time) to stay above 100. It'll creep up to a 2000-3000 then drop back down to 100 and will continue in this see-saw fashion.


There are 2 new verbose outputs:

    gaplist: The number of sieved gaps ready for scanning
    block: The percent of the calculation amount of an average block

When mining with the CRT, the primes/sec and block values are estimated using the theoretical speed improvements from CRT so may not be accurate.

Mining with the CRT is optimized for solo mining. Pool miniing with CRT is possible but will probably result in fewer shares (the primes/sec and block values are probably inaccurate) but the chance of finding a block is almost the same as when mining solo.