user78: http://www.bitfreak.info/files/pp2p-ccmbc-rev1.pdf

This paper will describe the way in which these three mechanisms can
  work together to form a system which provides a high level of
  integrity and security, yet is much slimmer than all other purely P2P
  currencies. It also offers other potential benefits such as faster
  transactions and lower fees, quicker network synchronization, support
  for high levels of traffic, more  block space for custom messages, and
  increased anonymity

Has anyone analyzed the design and found it to be secure? My own primitive analysis didn't find any weaknesses, but I'm no cryptographer or security expert.

user6116: Rosenfeld's answer is pretty much correct. Note however that the attack can only be successful if the attacker generates a fake chain in secret and then starts broadcasting the fake chain after the mini-blockchain has completed a full cycle (and providing that the attacker has managed to keep up with the real chain).
We are aware of this attack vector and we've developed a contingency plan to deal with it should it ever occur. The paper sourced by the question asker is a little bit outdated now, we have a project wiki which covers a lot of things that the paper skipped over. The Weaknesses and attack vectors page of the wiki discusses the "secret chain attack".

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 node
  will simply refuse to participate in the network until the situation
  has been resolved.
It's unlikely the attack could last very long without the help of new
  nodes but just in case the community will release a new checkpoint
  pointing to the right chain 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, this strategy is an acceptable contingency
  plan for dealing with the attack. Worse case scenario is that new
  nodes have to wait until a new checkpoint is released which points to
  the real chain. Businesses already running a node would not be
  affected in any way.


user575: The most apparent weakness is the following: If an attacker has enough hashpower to build an alternative branch starting with the current block, and to be ahead of the network once that block is pruned; he can rewrite the entire history completely, assigning bitcoins arbitrarily among the addresses he chooses.
This can be alleviated with archive nodes which are consulted in times of emergency.

78: <p><a href="http://www.bitfreak.info/files/pp2p-ccmbc-rev1.pdf" rel="noreferrer">http://www.bitfreak.info/files/pp2p-ccmbc-rev1.pdf</a></p>

<blockquote>
  <p>This paper will describe the way in which these three mechanisms can
  work together to form a system which provides a high level of
  integrity and security, yet is much slimmer than all other purely P2P
  currencies. It also offers other potential benefits such as faster
  transactions and lower fees, quicker network synchronization, support
  for high levels of traffic, more  block space for custom messages, and
  increased anonymity</p>
</blockquote>

<p>Has anyone analyzed the design and found it to be secure? My own primitive analysis didn't find any weaknesses, but I'm no cryptographer or security expert.</p>
 6116: <p>Rosenfeld's answer is pretty much correct. Note however that the attack can only be successful if the attacker generates a fake chain in secret and then starts broadcasting the fake chain after the mini-blockchain has completed a full cycle (and providing that the attacker has managed to keep up with the real chain).</p>

<p>We are aware of this attack vector and we've developed a contingency plan to deal with it should it ever occur. The paper sourced by the question asker is a little bit outdated now, we have a project wiki which covers a lot of things that the paper skipped over. The <a href="http://bitfreak.info/mbc-wiki/index.php?title=Weaknesses_and_attack_vectors" rel="nofollow">Weaknesses and attack vectors</a> page of the wiki discusses the "secret chain attack".</p>

<blockquote>
  <p>The Secret Chain Attack</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>Minimizing risk of attack success</p>
  
  <p>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 node
  will simply refuse to participate in the network until the situation
  has been resolved.</p>
  
  <p>It's unlikely the attack could last very long without the help of new
  nodes but just in case the community will release a new checkpoint
  pointing to the right chain 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.</p>
  
  <p>Since this attack will only put new nodes at risk and since it will
  most likely never happen, this strategy is an acceptable contingency
  plan for dealing with the attack. Worse case scenario is that new
  nodes have to wait until a new checkpoint is released which points to
  the real chain. Businesses already running a node would not be
  affected in any way.</p>
</blockquote>
 575: <p>The most apparent weakness is the following: If an attacker has enough hashpower to build an alternative branch starting with the current block, and to be ahead of the network once that block is pruned; he can rewrite the entire history completely, assigning bitcoins arbitrarily among the addresses he chooses.</p>

<p>This can be alleviated with archive nodes which are consulted in times of emergency.</p>
