Have you found any blocks with these changes? My very poor understanding of the algorithm suggests that changing the has factor will not work...

No - I only was testing based on some of Koooooj's comments to see if there was a possible tradeoff.

The primecoin paper says:

In one case, varying nonce and finding a block header hash that is divisible by a small

primorial number – the product of all primes smaller than a given prime p – can help

only slightly. It allows the prime miner to work on somewhat smaller primes, like maybe

a few digits shorter, for prime numbers of typically 100 digits, only a very small

advantage.

which suggested further that this is only used to help make finding candidates faster.

--------

Related, I finally was able to coerce primecoind to compile on FreeBSD. Here are some stats for an HP DL 585 w/64 cores -- which is actually almost the same for 5-chains as the cc2.8xlarge:

2013-07-19 07:21:20 primemeter 52706242 prime/h 409095802 test/h 2700 5-chains/h

2013-07-19 07:22:20 primemeter 55256799 prime/h 430313188 test/h 2820 5-chains/h

2013-07-19 07:23:20 primemeter 57252732 prime/h 451175301 test/h 3180 5-chains/h

2013-07-19 07:24:20 primemeter 60431918 prime/h 472296745 test/h 2280 5-chains/h

2013-07-19 07:25:20 primemeter 49530089 prime/h 384528982 test/h 2460 5-chains/h

2013-07-19 07:26:20 primemeter 51512423 prime/h 400527689 test/h 1980 5-chains/h

If you're interested in compiling for FreeBSD, you also will need to install the usual libraries and also change

**init.cpp**:

// nMaxConnections = std::max(std::min(nMaxConnections, FD_SETSIZE - nBind - MIN_CORE_FILEDESCRIPTORS), 0);

nMaxConnections = std::max(std::min(nMaxConnections, static_cast<int>(FD_SETSIZE - nBind - MIN_CORE_FILEDESCRIPTORS)), 0);

I had to specify the install paths for a lot of things and remove the explicit -ldl in the makefile as well.. go figure.

Did you test with other number aswell?

Yes, I did 10, 11, 12, 13, 14, 15, 16, 17. It starts to get bad around 13 on the big aws instance.

I could be wrong, but I'm not convinced this change will make any significant difference. The primorial of 7 is the same as that of 9, since 8 and 9 aren't primes.

No this is not what primorial means.

primorial(1) = 2

primorial(2) = 2 * 3

primorial(3) = 2 * 3 * 5

and so forth.

primorial(7) = 2 * 3 * 5 * 7 * 11 * 13 * 17 = 510510

primorial(9) = 2 * 3 * 5 * 7 * 11 * 13 * 17 * 19 * 23 = 223092870

Notice the list of divisors this produces when using p#9 * some random price

> bc

print 223092870 * 498497689

111211280127377430

http://www.wolframalpha.com/input/?i=factor+%28111211280127377430%29Honestly I can't say I really understand what the code is doing here, but based on some the comments from Kooooooj and running through gprof, Weave is sucking up all the time -- so I was trying to push some of the work out of there and into the caller function. I am 100% speculating also that the increases in difficulty may make the primorial a little more important. But anyway, mostly just hacking.

oh well, off to bed.