View source for 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 wouldn't affect older nodes who have been validating blocks for longer than the cycle of the [[mini-blockchain]] because they could easily detect that the fake chain appeared out of thin air. If it appears to the node as if the chain popped out of thin air the node will simply assume that the chain has no valid origin point.

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 suceed, 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


===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.