Security within a deleting blockchain model

1

Assume a blockchain model that contained no transaction data - just pure data. After a set time this data would simply be deleted, and entire blocks would be removed. How would the security model of the blockchain suffer? Would it make it easier for a "long chain" attack, and if so how can this be prevented?

The idea is to store data into the blockchain. Anyone could store data in this chain, and all nodes have a copy of this chain. There is a block race, to secure the blockchain as normal, but there would be no rewards since this is not a money based system. How the deletion is done is yet to be explored, but basically all nodes would agree all blocks older than x months be deleted from their systems.

Would an attacker be able to compute a longer chain if they know of the point at which data is deleted, then show this to the network and then make the network believe this is the correct and valid chain? If so, how can we stop this? (Assume the attacker has less than 51% computing power.) I have looked into timestamps, and time capsule based encryption, but what I want is a mechanism where an attacker cannot successfully create a block without some information that would only be revealed on a specific day.

user1243234

Posted 2016-02-10T20:18:02.220

Reputation: 11

2Are you talking about a rolling mini-blockchain without a financial incentive? Your question is a bit brief on the details of your scenario, could you elaborate? – Murch – 2016-02-10T20:41:01.290

Securing the blockchain against reorganization is easy as Nick has shown. Your problems are rather with a) adding new users to the system (how do they know which blockchain is the real one?), and b) with the incentives: As the miner decides what data gets included in a block, there is a strong incentive to be the miner, but if you aren't paying or mining it yourself, why would anyone include your data over their own in the block? Once difficulty goes beyond what you can mine yourself, the only way for you to get your data into the chain would be to fork it. – Murch – 2016-02-11T08:26:39.280

related: Mini-Blockchain proposal: How is the proof-chain secured against injections?, Is the "Finite Blockchain" idea secure?

– Murch – 2016-02-11T08:34:26.193

Answers

1

Your system is pretty easy to implement. The major reason why Bitcoin nodes don't delete old blocks is that old transactions are needed to tell if new blocks are valid. But if the validity of new blocks doesn't depend on old blocks, than the contents of those blocks can be deleted without consequences.

You mention the problem of having a node on the network pretend that an old block is new. Bitcoin solves this problem in three ways:

Separate block header and block contents; keep block header forever

Bitcoin block headers are 80 bytes. They look like this:

<4 byte version> <32 byte hash of previous block header>
<32 byte hash of the block contents>  <4 byte timestamp>
<4 byte difficulty> <4 byte nonce>

That's small enough to avoid having to delete the block headers, ever, but enough to include a merkle root of what's in the block. You can delete the block, but keep the block header around. The difficulty field is necessary because Bitcoin difficulty can vary. The 4 byte nonce is added to make mining easier.

Record timestamp in block header

The timestamp is recorded in the block header, and the Bitcoin client rejects any block headers that are too far into the future or the past.

Record previous block in block header

Bitcoin includes the hash of the previous block header in the block header, which means that you can't take a previous set of block headers and pretend that they're new.

For example, if you've got these block headers:

A>B>C>D>E

You can't take C and append it to E, because other nodes will notice the mismatch between E and C's parent, B.

Nick ODell

Posted 2016-02-10T20:18:02.220

Reputation: 26 536

Asked: 2016-02-10T20:18:02.220

Viewed: 502 times

Active: 2016-02-10T23:40:13.943