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.
Let's suppose you have 10% of stake and an alien's computer stolen from Area 51. Odds to generate 60 block long chain at the rate of 1 block a minute are very small (something like 1/10000000000000...) Cumulative difficulty of your branch will be much lower than difficulty of the main chain and it won't be accepted by other peers (you can generate your chain very fast with timestamps far in the future). You continue and now begin searching for private keys that can give you public keys with hits very close to zero (let's call them attacking accounts). You have to do a lot of Ed25519 computations (requires much more CPU power than SHA256) but you have an alien's computer and you complete the task within 2 minutes. Now you have to go to Area 51 again and stole a time machine or wait for a few months (otherwise blocks of your chain won't be accepted due to incorrect timestamps).
Let's think how to counteract the attack.
The first thing that has come to my mind is to extend maturity period from 60 (1 hour) to 1440 blocks (1 day). This will force you to wait for years and even after that you will not be able to complete the attack because of checkpointing. I don't really like to wait for 1 day before I start generating blocks, I will think more and may come to another solution.
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
I'm sorry that I misinformed you. It's true that the target on the 2-second mark is 2 times bigger than on the 1-second mark, but it's only because each second the target grows by 1/60 of the base target. On the 3-second mark it will be 3 times bigger than on mark 1, and 1.5 times bigger than on mark 2.
Target = BaseTarget * TimeSincePreviousBlock / 60
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.
It is already implemented, all new blocks must be within +/- 15 seconds.
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.
Is there any other attack except Cunicula attack described above? That one requires a lot of resources.
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.
Nxt uses accounts, not inputs/outputs (payment privacy is supposed to be provided via mixing feature). Each 525949th block (1 year) the blockchain will be shrunk (and checkpointed).
Show Posts
