4

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.

|improve this question
3

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.

|improve this answer
  • 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 Jul 22 '13 at 17:56
  • @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 Jul 22 '13 at 18:35
  • 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 Jul 26 '13 at 10:46
  • @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 Jul 26 '13 at 13:18
  • @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 Jul 27 '13 at 12:44
1

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.

|improve this answer
  • 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 Jul 28 '13 at 18:17
  • @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 Jul 28 '13 at 19:55
  • @ripper234: that's why new nodes will refuse to participate in the network until the situation has been resolved. – bitfreak Jul 29 '13 at 1:24
  • @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 Jul 29 '13 at 10:09
  • @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 Jul 29 '13 at 10:45
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

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.