Valid point. Will adding a generation delay for novel keys solve this problem? 60 blocks (~1 hour) to wait until someone is able to generate blocks, what do you think?
I don't think that will work.
Suppose I have 0.001% of stake and vast computing power. All I have to do to attack is construct a 60 block private chain and then I can use my computing power to extend this chain to an arbitrary length.
The 60 block hurdle might be enough to prevent atack if it took years to construct. However, it doesn't. In practice, an attack chain will be just marginally slower than a legit chain. This will remain true even if the attacker has only say 0.001% of stake.
Recall that the target halves every second. If 99.999% of stake can conetruct a block in 60 seconds on average, then 0.001% of stake will be able to construct a block in 77 seconds on average. So it will only take about an hour and 15 minutes to execute an PoW based attack with a 60 block delay.
The target falls so quickly that you are relying very heavily on synchronous time in the process.
In your system:
target = difficulty constant * exp (-0.7t) where t is measured in seconds
A very slight misrrporting of the timestamp offers a tremendous advantage.
I suggest the following modification
target = difficulty constant * exp (-0.7 ln (t))
Under this adjustment, our 0.001% attacker would needs 173 days per attack block instead of 77 seconds.
This is still not enough though.
If we are dealing with a 10% attacker then he would need about 25 minutes per attack block, so with a 60 block delay, he could execute a PoW based attack in a couple of days.
To solve the problem, you also need to prevent users from controlling the seed used to generate the hit entirely.
I think you should assign each satoshi a permanent color. Say the color is indexed by an integer from 1 to 1 billion (1 billion satoshis, right?).
Then the miner generates a unique hit for each satoshi under his control. The hit for each satoshi should be determined by
Hash (satoshi color, block height)
So over the long run all satoshis are equal in terms of mining power.
I also think you should implement the modified rule for target descent shown above. The target drops much to quickly with time in your current design. Under my modified rule, the target halves with every doubling in waiting time. So it halves between ..., 15 and 30 seconds,30 and 60 seconds, and then halves again between 60 and 120 seconds, and so on
Finally, you need to enforce synchronicity more stringrently than bitcoin. Blocks that are timestamped ahead of user time should be rejected (at least until user time catches up with them). Comparing chains of equivalent length and differing only in the current block, you should have the client choose whichever current block has an earlier timestamp as the correct chain.
The last issue is the lack of any resource cost associated with a failed attack attempt. I'm willing to believe that this is just a theoretical concern (and ignore it). It is very complicated to solve under a pure POS system. You should be prepared, however, for a lot of criticism on this aspect.
BTW are you planning to use centralized checkpoints for each block as in PPC? Please don't. This is a good way of ruining your credibility. If you don't use checkpoints, then you will have a very clear point of differentiation from PPC.
