But if you targeting higher shifts anyway, than the CRT could make a difference!
I'm currently testing my implementation within testnet,
but It will still probably take some time till it's ready.
Just wanted to let you know, that I'm working on something.
I also want to thank you all for the great support from all of you!
Thanks, will be great to see CRT improvements. Will using default --sieve-primes and --sieve-size still be what to use on larger shifts with the new miner?
The website now parses all gaps from
http://www.trnicely.net/ till 20k, which is currently
not very efficient implemented, so I set the refresh interval to 4 hours,
once the new miner is finished, I'll take care of it.
Noticed the new records list on gapcoin.org now includes the shift used, definitely makes it easier to search whether or not you set a record after the fact.