So, I was reading this paper 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.

1 Answer 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?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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