Weaknesses and attack vectors

Weaknesses

Less Flexible

Script is not used within the mini-blockchain scheme. Since the account tree holds the final balance of all non-empty addresses and is not reliant on interlocking transactions like Bitcoin it's not possible to use scripts which must be solved at a later time because transactions in the mini-blockchain are discarded after a relatively small period of time (the length of the mini-blockchain cycle time).

However, it is still possible to allow more complex types of transactions such as a multi-signature transactions, and by not utilizing script we get the advantage of making many aspects of the system exceptionally simpler and at the same we get an increased level of security because every type of possible transaction will be very well defined, eliminating the risk of an unforeseen script causing havoc on the network.

It's also clear that most people really just want simple types of transactions, most people don't even use multi-signature transactions, what they mostly want is basic banking tools. If we want this extreme level of scalability we're going to have to give up some flexibility, and that's not such a bad trade off considering that Bitcoin already has pretty strict rules about what transactions are considered standard format.

Attack Vectors

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:

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

Double-Spending

With most crypto-currencies which use a typical blockchain scheme merchants are protected from double-spending to a degree which depends on how many confirmations they want before deciding the payment is valid. The more confirmations a transaction has, the deeper it is buried into the blockchain and the less likely it is to be orphaned.

However if a merchant is willing to accept a 0-confirmation transaction an attacker can exploit this oversight and send multiple payments to different addresses, emptying their balance before the merchant can get paid. This same weakness applies to the mini-blockchain scheme however we have multiple methods of minimizing the risk of it happening.

Minimizing risk of attack success

The primary method for reducing the risk of double-spending is to implement withdrawal limits which will help make low-confirmation transactions more secure. By allowing users to set a withdrawal limit on their accounts a merchant can see the balance and withdrawal limit of the buyers address and be assured that the buyer cannot empty their account within a small amount of time.