<p>And how exactly would the network agree on the last included block in order to spawn <em>your</em> new blockchain? That would be kind of complicated.</p>

<p>In my opinion Merkle tree is already fixing the problem. Downloading the headers of each block is enough to verify payments.</p>

<p>Remember that only miners actually need all of the blockchain data. Clients don't.</p>

CC BY-SA 3.0
2014-01-13T01:05:31.563Z
2014-01-13T01:14:11.570Z
2014-01-13T01:14:11.570Z
Luca Matteis
<p>Pruning the whole Bitcoin ledger information is possible, and there are some alternative clients that use that, to reduce de current block chain a lot, but recreating a new block chain with only the unspent outputs is not that easy as it sounds as that would require regenerating all the hashes according to the difficulty at each time.</p>

<p>Even with the increasing hashing power (which is not guaranteed to continue that way) it will be an enormous task to recreate a pruned valid block chain. Also, there will be some problems with snapshot block hashes that are inside the client code.</p>

<p>If you go for another system that avoid creating a valid block chain, then I think that it is already possible for non-mining nodes. Some light clients will trust some kind of central server that has the full block chain. That way, you can get a reduced version or just delegate transacion verification to it.</p>

<p>If the client is modified that way for mining nodes having only one "trusted" server, it could be a solution, but then you have a centralized server and not a <a href="https://en.wikipedia.org/wiki/Peer-to-peer" rel="nofollow">P2P</a>.</p>

<p>So to get a fully decentralized system you need to be able to trust no one and thus having all the information on your own is the only way without reimplementing the whole protocol to create a new reduced blockchain that is safe and unique. </p>

CC BY-SA 3.0
2014-01-11T10:53:02.767Z
2014-01-12T11:18:24.600Z
2014-01-12T11:18:24.600Z
frisco
<p>Individual clients could do this; if they select an (arbitrary) starting block, and calculate the location of all the bitcoins at that time, they could start off from there. They would be unable to see transactions that happened before this, of course, but they would know all the balances.</p>

<p>For example, as I write this, we are at block 286293; I could call this my "first" block (after verifying every transaction leading up to it), with a "starting block hash" of  0000000000000000258d8d361e9510df41e6da81751c98134083bf167088390 and make a list of all the balances so far. My software would be completely compatible with all other bitcoin software, except that it takes on faith that this is the starting block, and it would be unable to view prior transactions.</p>

<p>This does depend on there not being a fork (or, at least, not being on the wrong side of the fork) at the new starting block. For this reason, I would expect such a block chosen would not be the most recent block, but, say, one that is a few days old. You would, of course, be depending absolutely on the trustworthiness of the starting block.</p>

<p>Most software already does a variation of this to save having to process the entire blockchain for every transaction it sees.</p>

CC BY-SA 3.0
2014-02-17T03:07:04.570Z
2014-02-17T03:15:19.630Z
2014-02-17T03:15:19.630Z
AMADANON Inc.
<p>I"m really wondering: you see 13 gigabytes (current blockchain size) is big enough only because there are all of transactions.</p>

<p>Can Bitcoin developers create such a piece of code which will shrink the size of the blockchain by collecting information of all addresses and representing some kind of inputs without using a <a href="https://en.wikipedia.org/wiki/Merkle_tree" rel="noreferrer">Merkle tree</a>, but in "database" style (like 4.5 bitcoins belongs to Alice, 2.3 belongs to Bob, ... ,.. .. and so on)</p>

<p>If blockchain size could be shrinked once in a year, then that would be a great solution.</p>

<p>Why isn't such a model allowable or what is the probability that Bitcoin developers will adopt this kind of protocol?</p>

<p>My solution here implies that everything on Bitcoin goes on the same way, but except for the fact that there will be a blockchain limit like 250 gigabytes for the blockchain - <em>once</em> the network will reach that limit, the network will agree on the last included block of transactions, after which the whole network will switch to a new blockchain file which won't wipe out everybody's bitcoins, but which will just create the <em>genesis blocks</em> based on previous files with all previous inputs belonging to their owner's addresses.</p>

<p>Please don't just say "it won't work".</p>

<blockchain>
Why can't we make the Bitcoin software start the blockchain from the beginning?
Abdo
# Why can't we make the Bitcoin software start the blockchain from the beginning?

(Asked by: username_0 on 2014-01-11)

I"m really wondering: you see 13 gigabytes (current blockchain size) is big enough only because there are all of transactions.

Can Bitcoin developers create such a piece of code which will shrink the size of the blockchain by collecting information of all addresses and representing some kind of inputs without using a [Merkle tree](https://en.wikipedia.org/wiki/Merkle_tree), but in "database" style (like 4.5 bitcoins belongs to Alice, 2.3 belongs to Bob, ... ,.. .. and so on)

If blockchain size could be shrinked once in a year, then that would be a great solution.

Why isn't such a model allowable or what is the probability that Bitcoin developers will adopt this kind of protocol?

My solution here implies that everything on Bitcoin goes on the same way, but except for the fact that there will be a blockchain limit like 250 gigabytes for the blockchain - *once* the network will reach that limit, the network will agree on the last included block of transactions, after which the whole network will switch to a new blockchain file which won't wipe out everybody's bitcoins, but which will just create the *genesis blocks* based on previous files with all previous inputs belonging to their owner's addresses.

Please don't just say "it won't work".

**Tags:** blockchain


---

## 3 answers

### Answer by username_1 on 2014-01-13. Score: 2

And how exactly would the network agree on the last included block in order to spawn *your* new blockchain? That would be kind of complicated.

In my opinion Merkle tree is already fixing the problem. Downloading the headers of each block is enough to verify payments.

Remember that only miners actually need all of the blockchain data. Clients don't.


---

### Answer by username_2 on 2014-01-11. Score: 1

Pruning the whole Bitcoin ledger information is possible, and there are some alternative clients that use that, to reduce de current block chain a lot, but recreating a new block chain with only the unspent outputs is not that easy as it sounds as that would require regenerating all the hashes according to the difficulty at each time.

Even with the increasing hashing power (which is not guaranteed to continue that way) it will be an enormous task to recreate a pruned valid block chain. Also, there will be some problems with snapshot block hashes that are inside the client code.

If you go for another system that avoid creating a valid block chain, then I think that it is already possible for non-mining nodes. Some light clients will trust some kind of central server that has the full block chain. That way, you can get a reduced version or just delegate transacion verification to it.

If the client is modified that way for mining nodes having only one "trusted" server, it could be a solution, but then you have a centralized server and not a [P2P](https://en.wikipedia.org/wiki/Peer-to-peer).

So to get a fully decentralized system you need to be able to trust no one and thus having all the information on your own is the only way without reimplementing the whole protocol to create a new reduced blockchain that is safe and unique.


---

### Answer by username_3 on 2014-02-17. Score: 0

Individual clients could do this; if they select an (arbitrary) starting block, and calculate the location of all the bitcoins at that time, they could start off from there. They would be unable to see transactions that happened before this, of course, but they would know all the balances.

For example, as I write this, we are at block 286293; I could call this my "first" block (after verifying every transaction leading up to it), with a "starting block hash" of 0000000000000000258d8d361e9510df41e6da81751c98134083bf167088390 and make a list of all the balances so far. My software would be completely compatible with all other bitcoin software, except that it takes on faith that this is the starting block, and it would be unable to view prior transactions.

This does depend on there not being a fork (or, at least, not being on the wrong side of the fork) at the new starting block. For this reason, I would expect such a block chosen would not be the most recent block, but, say, one that is a few days old. You would, of course, be depending absolutely on the trustworthiness of the starting block.

Most software already does a variation of this to save having to process the entire blockchain for every transaction it sees.


---

