<p>While I didn't see it addressed explicitly in the paper, the attack could be defeated by requiring a competing blockchain to have <strong>common ancestry in the proof-chain</strong> in order for it to be considered. </p>

<p>Out of the proposed triplet account-tree, mini-blockchain, and proof-chain, the proof-chain has by far the least memory requirement with only 512 bit (64 byte) per element. If applied to a coin with a blocktime of 1 minute, one year worth of proof-chain would only have 32 megabytes (containing 525600 proofhashes), while one year worth of proof-chain should be sufficient to allow for any valid competing chains.</p>

<p>The above assumes of course that each of the triplet does what it should be doing. I had one follow-up question though, posted here: <a href="https://bitcoin.stackexchange.com/q/25184/5406">Mini-Blockchain proposal: How is the proof-chain secured against injections?</a></p>

CC BY-SA 3.0
2014-05-08T09:27:18.683Z
2014-05-08T09:27:18.683Z
2017-04-13T12:47:33.610Z
Murch
<p>So, I was reading <a href="http://bitfreak.info/files/pp2p-ccmbc-rev1.pdf" rel="nofollow">this paper</a> as a proposal to the ever growing blockchain problem. In summary, it's security is provided without a full blockchain by having a proof chain with these fields:</p>

<ul>
<li>Previous proof block hash</li>
<li>block header hash</li>
</ul>

<p>Now this is all fine, but one problem I see is what if 2 coins were to adopt this scheme? If one chain was vastly more powerful than another, than an attacker could take the other blockchain and build fake transactions and blocks onto it and then introduce it to the weaker coin's peers. The peers would see it as having a higher overall difficulty/length and adopt it. Other than verifying the genesis block's hash and embedding it within the peer/wallet software, is there any other way to prevent this attack? The paper also mentions trimming extremely old proof blocks, but that doesn't appear to be possible to securely do if the genesis block could be pruned from the proof chain. </p>

<blockchain><alternatives><academic-research><mining-technical-details>
If more than one coin did the "mini-blockchain" proposal, would that make the weaker coin vulnerable?
Earlz
# If more than one coin did the "mini-blockchain" proposal, would that make the weaker coin vulnerable?

(Asked by: username_0 on 2014-03-28)

So, I was reading [this paper](http://bitfreak.info/files/pp2p-ccmbc-rev1.pdf) as a proposal to the ever growing blockchain problem. In summary, it's security is provided without a full blockchain by having a proof chain with these fields:

* Previous proof block hash
* block header hash

Now this is all fine, but one problem I see is what if 2 coins were to adopt this scheme? If one chain was vastly more powerful than another, than an attacker could take the other blockchain and build fake transactions and blocks onto it and then introduce it to the weaker coin's peers. The peers would see it as having a higher overall difficulty/length and adopt it. Other than verifying the genesis block's hash and embedding it within the peer/wallet software, is there any other way to prevent this attack? The paper also mentions trimming extremely old proof blocks, but that doesn't appear to be possible to securely do if the genesis block could be pruned from the proof chain.

**Tags:** blockchain, alternatives, academic-research, mining-technical-details


---

## 1 answers

### Answer by username_1 on 2014-05-08. Score: 1

While I didn't see it addressed explicitly in the paper, the attack could be defeated by requiring a competing blockchain to have **common ancestry in the proof-chain** in order for it to be considered.

Out of the proposed triplet account-tree, mini-blockchain, and proof-chain, the proof-chain has by far the least memory requirement with only 512 bit (64 byte) per element. If applied to a coin with a blocktime of 1 minute, one year worth of proof-chain would only have 32 megabytes (containing 525600 proofhashes), while one year worth of proof-chain should be sufficient to allow for any valid competing chains.

The above assumes of course that each of the triplet does what it should be doing. I had one follow-up question though, posted here: [Mini-Blockchain proposal: How is the proof-chain secured against injections?](https://bitcoin.stackexchange.com/q/25184/5406)


---

