Quote from: psychocoin on July 31, 2014, 09:00:30 PM

The design looks very vulnerable to 51% type attacks, much more so than Bitcoin even. Wouldn't trust it with my money.

At least you have taken the time to come up with a reasonably valid criticism that is worth talking about. I believe what you are referring to is the Secret Chain Attack. Following quote taken from the weaknesses and attack vectors wiki page.

Quote

The Secret Chain Attack

If an attacker had enough hashing power he could generate a fake chain in secret using the real proof chain but a fake account tree. He would need to out-pace the real mini-blockchain for a full cycle until there's no evidence left to indicate his account tree is fake and then start broadcasting the fake chain.

This wont affect older nodes who have been validating blocks for longer than the cycle of the mini-blockchain because they can detect the fake chain or simply ignore super long forks. In Cryptonite existing nodes will just stick with the chain they have if the origin point of the fork appears to be older than the cycle time.

So there's no way the attacker could trick existing nodes to accept his fake chain, but new nodes are still at risk. New nodes have no way of determining which is the valid chain because they have no history of what happened before the oldest block in the mini-blockchain. Using some sort of consensus mechanism is not perfect either.

Minimizing risk of attack success

If a new node detects multiple chains which originate from the same proof chain it can try to query other nodes for older blocks all the way to the block in which the competing chains diverged and if no one around has this long history (no one is required to have it) the user can either take a chance on the chain the nodes recieves first, or refuse to participate in the network until one of the chains has won the race.

The user will be warned when any type of fork longer than 24 hours is detected. The user could also manually point the node to the correct chain with the use of a community checkpoint. The community will release a new checkpoint as quickly as possible if this situation does arise. When the checkpoint is released new nodes will be able to safely join the network and help the other nodes work against the attacker.

Since this attack will only put new nodes at risk and since it will most likely never happen, let alone succeed, this strategy is an acceptable contingency plan for dealing with the attack. Worse case scenario is that new nodes have to wait until the situation has been resolved or wait until a new checkpoint is released which points to the real chain. Anyone already running a node would not be affected in any way.

In summary, this attack is unconcerning and unlikely for several reason:

* requires an incredible amount of hashing power
* requires that no one has historic blockchain data
* only nodes which haven't synced for more than a week are susceptible
* when all else fails new nodes can resolve the problem with a checkpoint
* attack will never succeed due to checkpoints and probably could never be profitable