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

CC BY-SA 3.0
2013-07-22T17:56:48.483Z
You hinted at this in your answer, but: you can attack the blockchain with any amount of hashpower. Say the chain lasts for 1 month. If you have 33% of the hashpower, you can launch a 51% attack by preparing for a month in advance.
Nick ODell
CC BY-SA 3.0
2013-07-22T18:35:33.680Z
@NickODell: That's not true. You can't prepare in advance because you don't know what hash you'll fork from in advance (That's why there is a proof chain in the design). But I've realized an attack is easier than I thought earlier, I've edited accordingly. (It still requires >50% to pull off consistently.)
Meni Rosenfeld
CC BY-SA 3.0
2013-07-26T10:46:38.303Z
The way I understand the concept, the entire `Proof Chain` should be kept (although the author talks about possibly trimming it, it's light enough to be kept indefinitely). If the proof chain is kept forever, won't an attacker have to duplicate all the work that went into producing the proof chain, as opposed to just starting from the current block onward? If this statement is true, then isn't the security the same as the Bitcoin blockchain?
ripper234
CC BY-SA 3.0
2013-07-26T13:18:26.937Z
@ripper234: The proof chain contains no information about what it is that it is proving. The attacker just picks the latest point in the chain which has no corresponding full block, and pretends that the account tree of the time was whatever he wishes - without anyone having the full block, no one can verify or reject this claim.
Meni Rosenfeld
CC BY-SA 3.0
2013-07-27T12:44:24.917Z
@MeniRosenfeld the proof chain itself contains no information about what its proving, *except the hash*. An attacker will have to come up with a block that hashes to this exact hash ... it's not like an arbitrary state can exist at that point (latest point without a corresponding full block).
ripper234
CC BY-SA 3.0
2013-07-27T18:20:22.097Z
@ripper234: He doesn't need to come up with a block. The corresponding block has already been deleted. Honest nodes don't need to present a block hashing to the recorded hash value, and neither does the attacker.
Meni Rosenfeld
CC BY-SA 3.0
2013-07-27T19:37:33.867Z
@MeniRosenfeld hmm...
ripper234
CC BY-SA 3.0
2013-07-28T12:03:40.357Z
@MeniRosenfeld - FYI, see bitfreak's answer.
ripper234
CC BY-SA 3.0
2013-07-22T17:49:30.417Z
2013-07-22T18:36:18.403Z
2013-07-22T18:36:18.403Z
Meni Rosenfeld
<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>

CC BY-SA 3.0
2013-07-28T18:17:29.150Z
The mitigation strategies do not seem very solid. `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` - it's not clear how the conflict is resolved, and how a DOS is prevented. `Since this attack will only put new nodes at risk` - but new nodes can become the majority, by number or hash power, and/or cause a fork.
ripper234
CC BY-SA 3.0
2013-07-28T19:55:34.960Z
@ripper234: The crux of the attack is that nodes don't keep old blocks, an attacker with a fake history is no different from an honest node with the real history. But if there are archive nodes exist with the old blocks, the conflict resolution is easy - the real history will have a block which will hash to the value of the proof chain, and the fake history will not.
Meni Rosenfeld
CC BY-SA 3.0
2013-07-29T01:24:50.257Z
@ripper234: that's why new nodes will refuse to participate in the network until the situation has been resolved.
bitfreak
CC BY-SA 3.0
2013-07-29T10:09:02.043Z
@MeniRosenfeld - I think the concept of archive notes is just not well defined enough. If the security of the network depends on archive nodes, then the entire scheme is just another form of "lite client" that some people will use, but for absolute security you'll need to run or trust an archive node.
ripper234
CC BY-SA 3.0
2013-07-29T10:45:58.213Z
@ripper234: the solution doesn't rely on archive nodes since no one is required to store any historic data, it's just one extra defense. The main idea is to stop new nodes from joining the network if they detect two competing chains which originate from the same proof chain. In this way we can minimize the number of nodes who adopt the fake chain. You are right though, the system doesn't provide the level of "absolute security" that bitcoin provides since it doesn't store everything right back to the genesis block. We do have to give up a little bit of security if we want the advantages.
bitfreak
CC BY-SA 3.0
2013-07-29T10:53:10.493Z
The point is though, if we can make it hard enough to pull off such an attack then we don't need absolute security. The system as it is described now offers a level of security which would be virtually impossible to defeat... even if the attacker could outpace the real chain in secret for a full cycle (the cycle is likely to be a week or more), the attacker will still have a very hard time getting people to accept his fake chain with the contingency plan that's in place. Although not entirely impossible, it would be virtually impossible for the attacker to succeed with his attack.
bitfreak
CC BY-SA 3.0
2013-07-28T12:01:57.233Z
2013-07-28T12:01:57.233Z
bitfreak
<p>If the chain is too big to fit on miners, the the archival nodes wont be able to send the chain to the miners.</p>

<p>The problem with comparing long chains is that you cannot hold them all in the computer at the same time.</p>

<p>If you must delete old blocks, I think it is better to implement slasher first.
With slasher, if the block is older than 2000 blocks ago, you can delete almost all of it.</p>

<p>You have to save a little... blockhash, LastClosedLedgerhash, hash of transactions in the block, and some POS signatures.</p>

<p>You can delete all the old transactions, and you can delete old ledgers. In this case an archive would work splendidly.
You could ask for any historic block from the archive and instantly be able to tell that it is a valid part of your chain.</p>

<p>My efforts: <a href="https://github.com/zack-bitcoin/basiccoin" rel="nofollow">https://github.com/zack-bitcoin/basiccoin</a> </p>

CC BY-SA 3.0
2014-05-09T14:48:01.730Z
2014-05-09T14:48:01.730Z
user9415
<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>

<blockchain><scalability>
Is the "Finite Blockchain" idea secure?
ripper234
# Is the "Finite Blockchain" idea secure?

(Asked by: username_0 on 2013-07-06)

<http://www.username_3.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.

**Tags:** blockchain, scalability


---

## 3 answers

### Answer by username_1 on 2013-07-22. Score: 3 | Accepted answer

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.

> **Comments:**
> **username_2**: You hinted at this in your answer, but: you can attack the blockchain with any amount of hashpower. Say the chain lasts for 1 month. If you have 33% of the hashpower, you can launch a 51% attack by preparing for a month in advance.  
> **username_1**: @username_2: That's not true. You can't prepare in advance because you don't know what hash you'll fork from in advance (That's why there is a proof chain in the design). But I've realized an attack is easier than I thought earlier, I've edited accordingly. (It still requires >50% to pull off consistently.)  
> **username_0**: The way I understand the concept, the entire `Proof Chain` should be kept (although the author talks about possibly trimming it, it's light enough to be kept indefinitely). If the proof chain is kept forever, won't an attacker have to duplicate all the work that went into producing the proof chain, as opposed to just starting from the current block onward? If this statement is true, then isn't the security the same as the Bitcoin blockchain?  
> **username_1**: @username_0: The proof chain contains no information about what it is that it is proving. The attacker just picks the latest point in the chain which has no corresponding full block, and pretends that the account tree of the time was whatever he wishes - without anyone having the full block, no one can verify or reject this claim.  
> **username_0**: @username_1 the proof chain itself contains no information about what its proving, *except the hash*. An attacker will have to come up with a block that hashes to this exact hash ... it's not like an arbitrary state can exist at that point (latest point without a corresponding full block).  
> **username_1**: @username_0: He doesn't need to come up with a block. The corresponding block has already been deleted. Honest nodes don't need to present a block hashing to the recorded hash value, and neither does the attacker.  
> **username_0**: @username_1 hmm...  
> **username_0**: @username_1 - FYI, see username_3's answer.  

---

### Answer by username_3 on 2013-07-28. Score: 1

username_1'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](http://username_3.info/mbc-wiki/index.php?title=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.

> **Comments:**
> **username_0**: The mitigation strategies do not seem very solid. `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` - it's not clear how the conflict is resolved, and how a DOS is prevented. `Since this attack will only put new nodes at risk` - but new nodes can become the majority, by number or hash power, and/or cause a fork.  
> **username_1**: @username_0: The crux of the attack is that nodes don't keep old blocks, an attacker with a fake history is no different from an honest node with the real history. But if there are archive nodes exist with the old blocks, the conflict resolution is easy - the real history will have a block which will hash to the value of the proof chain, and the fake history will not.  
> **username_3**: @username_0: that's why new nodes will refuse to participate in the network until the situation has been resolved.  
> **username_0**: @username_1 - I think the concept of archive notes is just not well defined enough. If the security of the network depends on archive nodes, then the entire scheme is just another form of "lite client" that some people will use, but for absolute security you'll need to run or trust an archive node.  
> **username_3**: @username_0: the solution doesn't rely on archive nodes since no one is required to store any historic data, it's just one extra defense. The main idea is to stop new nodes from joining the network if they detect two competing chains which originate from the same proof chain. In this way we can minimize the number of nodes who adopt the fake chain. You are right though, the system doesn't provide the level of "absolute security" that bitcoin provides since it doesn't store everything right back to the genesis block. We do have to give up a little bit of security if we want the advantages.  
> **username_3**: The point is though, if we can make it hard enough to pull off such an attack then we don't need absolute security. The system as it is described now offers a level of security which would be virtually impossible to defeat... even if the attacker could outpace the real chain in secret for a full cycle (the cycle is likely to be a week or more), the attacker will still have a very hard time getting people to accept his fake chain with the contingency plan that's in place. Although not entirely impossible, it would be virtually impossible for the attacker to succeed with his attack.  

---

### Answer by username_4 on 2014-05-09. Score: 0

If the chain is too big to fit on miners, the the archival nodes wont be able to send the chain to the miners.

The problem with comparing long chains is that you cannot hold them all in the computer at the same time.

If you must delete old blocks, I think it is better to implement slasher first.
With slasher, if the block is older than 2000 blocks ago, you can delete almost all of it.

You have to save a little... blockhash, LastClosedLedgerhash, hash of transactions in the block, and some POS signatures.

You can delete all the old transactions, and you can delete old ledgers. In this case an archive would work splendidly.
You could ask for any historic block from the archive and instantly be able to tell that it is a valid part of your chain.

My efforts: <https://github.com/zack-bitcoin/basiccoin>


---

