<p>The idea of Bitcoin is that you can obtain the current state of the network without having to trust anyone. You essentially rely on the fact that the state that has most work put into it, is the valid state, and that all transactions are chained together up until the genesys block, after which there are no more transactions.</p>

<p>Now if you were to truncate this state (the block chain) in half, you could hard code this information into the software and it could reach some form of consensus among the nodes of the network. However this opens the door for attacks, because a dishonest node could easily fake and send you a wrong block height information, perhaps making you believe that a different history happened before the truncation of the block chain. And it could do this by simply broadcasting chunks of the history that was truncated, because lots of work has been put in that chunk and your client is programmed to accept longest worked on chains.</p>

<p>You would really have no way of knowing unless you read the entire history yourself.</p>

CC BY-SA 3.0
2014-05-15T13:41:20.827Z
Thanks, but I should ask in a more concise way that I'd like to dip into tech details. If mining is not involving/safe enough to do without actual history records in blockchain we can clean up the history redundancy. The only question is here that I do not know how the merkle tree is generated. Can anyone explain me an abstract model that takes in (previn) and outputs (stdout), showing in a diagram?
asn-0184
CC BY-SA 3.0
2016-12-06T18:20:24.227Z
No, nobody could fool you.   If you truncate the chain a year ago, saving the aggregated state, and the old block hash, all you'd need to do is ignore anything that doesn't hash to the longest chain, offset by your truncation.   There's no way a fork can reach back a year, so you're good.   Clients do this all the time.   And since you reached your *own* conclusion and cache state... you didn't have to trust anyone to do it.
Erik Aronesty
CC BY-SA 3.0
2014-05-15T07:48:51.507Z
2014-05-15T07:56:20.830Z
2014-05-15T07:56:20.830Z
Luca Matteis
<p>AFAIK, verification of transactions on the blockchain doesn't require the full chain data and six to ten verification will be enough (which makes uses of a <a href="https://en.wikipedia.org/wiki/Merkle_tree" rel="nofollow">Merkle tree</a>). Thus, why cannot it abridge the data for a future complete node?</p>

CC BY-SA 3.0
2014-05-15T07:52:54.687Z
I think it's healthy to re-ask questions since that one was asked more than 2 years ago.
Luca Matteis
CC BY-SA 3.0
2014-05-15T20:49:24.130Z
@LucaMatteis: The situation hasn't changed from when that question was answered. The protocol of Bitcoin still works the same.
Greg Hewgill
CC BY-SA 3.0
2014-05-17T15:24:17.927Z
@GregHewgill I found not technique detailed description on this. It seems I have to read source code.
asn-0184
<blockchain>
Why doesn't the Bitcoin blockchain truncate past data?
asn-0184
# Why doesn't the Bitcoin blockchain truncate past data?

(Asked by: username_0 on 2014-05-14)

AFAIK, verification of transactions on the blockchain doesn't require the full chain data and six to ten verification will be enough (which makes uses of a [Merkle tree](https://en.wikipedia.org/wiki/Merkle_tree)). Thus, why cannot it abridge the data for a future complete node?

**Tags:** blockchain

> **Comments:**
> **username_1**: I think it's healthy to re-ask questions since that one was asked more than 2 years ago.  
> **username_2**: @username_1: The situation hasn't changed from when that question was answered. The protocol of Bitcoin still works the same.  
> **username_0**: @username_2 I found not technique detailed description on this. It seems I have to read source code.  

---

## 1 answers

### Answer by username_1 on 2014-05-15. Score: 4

The idea of Bitcoin is that you can obtain the current state of the network without having to trust anyone. You essentially rely on the fact that the state that has most work put into it, is the valid state, and that all transactions are chained together up until the genesys block, after which there are no more transactions.

Now if you were to truncate this state (the block chain) in half, you could hard code this information into the software and it could reach some form of consensus among the nodes of the network. However this opens the door for attacks, because a dishonest node could easily fake and send you a wrong block height information, perhaps making you believe that a different history happened before the truncation of the block chain. And it could do this by simply broadcasting chunks of the history that was truncated, because lots of work has been put in that chunk and your client is programmed to accept longest worked on chains.

You would really have no way of knowing unless you read the entire history yourself.

> **Comments:**
> **username_0**: Thanks, but I should ask in a more concise way that I'd like to dip into tech details. If mining is not involving/safe enough to do without actual history records in blockchain we can clean up the history redundancy. The only question is here that I do not know how the merkle tree is generated. Can anyone explain me an abstract model that takes in (previn) and outputs (stdout), showing in a diagram?  
> **username_3**: No, nobody could fool you.   If you truncate the chain a year ago, saving the aggregated state, and the old block hash, all you'd need to do is ignore anything that doesn't hash to the longest chain, offset by your truncation.   There's no way a fork can reach back a year, so you're good.   Clients do this all the time.   And since you reached your *own* conclusion and cache state... you didn't have to trust anyone to do it.  

---

