Looks like that transaction never made it to the network. Unsent transactions are stored in the wallet.dat file. If you keep the wallet running, it should eventually resend that transaction. Did you check whether the date and time were correct?

If you want to get rid of the unconfirmed transaction, you can use -salvagewallet which will extract only the private keys from your wallet and ignores the transactions. As always, it's best to make a copy of your wallet.dat before doing this.

Thanks Sunny. That's what I suspected would happen.

That's not quite right. The primorial that is embedded in the chain origin actually changes the probability a lot. If you filter out the prime p_i, the probability increases by

1 / (1 - 1/p_i)

If you take a product of those up to p_17 which is 59, you get 7.47493. So that's how many times bigger the probability will be if the number is a multiple of 59#. Also, I usually assume that the numbers are about 300 bits in size. So then the probability for the 10th number being prime becomes:

7.47493 * 1/ln(2^300) = 0.0359468

And if I plug that number into your calculations, I get:

Sieve Size 9:
9-chains per day: 0.54 (reported by miner)
10-chains per day: 0.54 * 0.0359468 = 0.0194113
block per day = 0.54*0.04 + 0.0194113 = 0.0410113

And now size 9 wins by a significant margin.

That's definitely interesting if you are seeing increased block production when targeting length 10 instead of 9.

I'm aware that the distribution of the fractional remainder isn't really uniform. That's one major issue which may be screwing up my calculations. I'll need to check how big the impact is at some point. I'll also need to double check my earlier calculations too. I have already accounted for the fact that lots of 9-chains are found when targeting length 10. In fact, I assumed that ten times more 9-chains are found than 10-chains when targeting length 10.


I would argue that the difficulty increase to the 9.3 range was caused by the momentum left after the transition to 9.0. The block rate was about 1.5 blocks/minute on July 22 after the transition to 9.0. Cutting that rate by 1/3 brings it to the target rate of 1 block/min. The difficulty rising to about 9.3 does just that. The chart also shows that the block rate was about 3.0 blocks/minute before the transition. That means that going from 8.996 to 9.0 somehow seems to have cut the block rate in half.


I looked at the fractional remainder a while back. I remember seeing a large number of 0xFFFFFF (this is the 24-bit version of the fractional difficulty) values which should statistically be nearly impossible (if you wanted to assume that it would be uniformly distributed).

Check the date (including year), the time and the timezone. Which block are you getting stuck on? You can compare that to the block count here:
http://primecoin.21stcenturymoneytalk.org/

Yes, my original formula here actually wasn't accurate for high fractional difficulties. The issue boils down to the probability of the 10th number being prime. I thought that the probability would be negligible but actually it is about 3.5% according to my estimates (this number depends on the primorial used during mining). That means that about 3.5% of 9+-chains turn out to be 10-chains (9+-chains refers to chains at least of length 9). As the fractional difficulty increases, the number of accepted 9-chains diminishes while the 10-chains remain unaffected. Eventually there will be more 10-chains qualifying for blocks than 9-chains.

So my latest estimate for the amount of blocks found is:
blocks/day = chains/day * (1 - fracDiff + 0.035)

There will be a jump in the difficulty when difficulty goes to 10.0. That's because none of the 9-chains will qualify for blocks and we have to start looking for 10+-chains. I've actually been working on a paper related to this. Right now it looks like 10.0 will be more difficult than 9.996 will be which means we could get stuck between 9.996 and 10.0 for a while.

You can actually see that happening before in my charts:
http://xpm.muuttuja.org/charts/

If you look closely enough, the network block rate seems to have dropped when we went from 8.996 to 9.0. Of course we were using an older version of the mining algorithm back then which probably behaved slightly different.

Well, you can try looking at the debug.log file to see if there's a cause there. The file is in the %APPDATA%\Primecoin folder since you're on Windows. If all else fails, you can try deleting the database files in that folder. Make sure to preserve wallet.dat though.

Multiplying the hash with small prime factors is simply a trick to increase the chances of finding a prime chain. Lets say we have a number N such that N = 2 * 3 * 5 * 7 * n, i.e. N is divisible by 2, 3, 5 and 7. Now we know that none of these numbers are divisible by these prime factors: N - 1, N + 1, 2N - 1, 2N + 1, 4N - 1, 4N + 1, ... .

Filtering out the prime factor p_i from a random number M increases the chances M being prime by 1 / (1 - 1/p_i). So if you filter out all even numbers, you double the chances. If you filter all numbers divisible by 3, you increase the chances by 50%. And if you filter out both, the chances are tripled.

CSieveOfEratosthenes is also increasing the chances of finding prime chains by filtering out all numbers divisible by slightly larger primes. The chances of finding a prime chain increase slightly with every prime factor that is filtered out. The details of this process are pretty complicated. I think the only place where the algorithm is described is the code itself.

Did you have the built-in miner running at the same time? AFAIK, those crashes occur randomly when mining. Also, some of your database files may be corrupt now because of the crash.

Simultaneous primes refers to a cluster of primes that are somehow connected to each other. 'k' is the number of primes in the cluster. Longer primes (in terms of how many digits you would need to write it down) are harder to find and are considered better. The first category where k=1 is equivalent to the largest known prime which is a Mersenne prime with a whopping 17425170 digits.

Primecoin is trying to find Cunningham chains. The primes in a Cunningham chain of the first kind follow the pattern:

n - 1
2n - 1
4n - 1
8n - 1
...
2^i * n - 1

As you can see all the primes are connected to 'n' which is called the origin. A Cunningham chain of the second kind looks like this:

n + 1
2n + 1
4n + 1
8n + 1
...
2^i * n + 1

Primecoin is looking for chains that are at least 9 primes long (so k >= 9). The current mining algorithm is producing numbers that are about 300-bits long which is about 90 digits. The origin is always a multiple of the block header hash which is 256 bits long. This hash is then multiplied by a few small prime numbers and a multiplier produced by our sieve algorithm. The miner can occasionally try using big multipliers which may result in a new record if the numbers are primes.

The origin is defined as the number next to the first prime in the chain (either -1 or +1 depending on chain type). In the case Primecoin, the primes are always odd, which means that the origin is even and thus is not a prime.

Yup, running a reindex should be one way to fix the issue. There's a bug in the Primecoin client which causes a crash if you start the miner when running -reindex. So make sure to specify -gen=0 to avoid that.

Actually, there is still a small loophole. It's possible to discovered a prime chain such that the origin has lots of factors in it. Sunny has outlined the idea in the v0.2 protocol proposal:
http://www.peercointalk.org/index.php?topic=453.0

It's not really realistic but the protocol is still getting tightened up in the future.

Well, you only need to get your wallet connected once and the issue should be fixed. Typing the addnode command in the debugging console should be easier.

That warning is given when no one on the network has a time within 5 minutes of your time. While it's possible you connected to bad peers, it's more likely that there is something wrong about your local date and time.


Can you also post the output of the commands 'getinfo' and 'getcheckpoint'?

Ah, you are right and I missed the decimal point when I did the division.

Primecoin actually uses a special block header hash which is different from the "block hash". It's not normally displayed anywhere.

The block header hash of block 200 000 is:
0xc4cb2d790a4edf8a9e11615b22b1c45eb0688c793a1d07a6464704750f6d9448 = 89012302118294945913527852560669227610448148164408794304935511321715883742280

And that does divide the prime origin:
http://www.wolframalpha.com/input/?i=87147097827283387491814940739178353533964145353273967578241214417087984945505448916205980486400+divided+by+89012302118294945913527852560669227610448148164408794304935511321715883742280

It's not the hash of the previous block, it's the hash of the current block that needs to divide the prime origin.

The hash of block 200 000 is:
0x4669276a932f5b16a718943a4930b5381bf9c7780ed45b2a751171d3feda174c = 31847690383992637018076344290348582925915863984630344106427592361057663457100

That hash divides the prime origin evenly.

The killall command in the script occasionally kills the script itself (it's supposed to only kill previously started scripts). Try commenting out the line:

The seed nodes are probably overloaded because of the amount of people joining the network again.

You can use my backup seed node by putting this in your primecoin.conf:

Well, your total chains/day is about 3.2 then. Since difficulty is about 9.86, that means only about 14% of chains will result in a block (because 1 - 0.86 = 0.14). Then we can estimate how many blocks you should get in a week:

3.2 chains/day * 7 days/week * 0.14 blocks/chain = 3.136 blocks/week

Of course chains/day isn't completely accurate, so let's assume that in reality it would be 20% lower (this is just a guess).

3.136 blocks/week * 0.8 = 2.5088 blocks/week

2.5 blocks isn't much as far as statistics are concerned. It is still very much possible that you simply got unlucky. That is unfortunately one of the realities of solo mining primecoins. If you want less variance, you can try one of the mining pools.