<p>The Bitcoin.org client v0.7 and lower will continuously increase in size about once every ten minutes, on average.</p>

<p>Blockchain.info provides a <a href="http://blockchain.info/charts/blocks-size" rel="nofollow">chart</a> showing the size of the data (actual disk consumption will be slightly larger even.)</p>

<p>The Bitcoin.org client v0.8, being developed now, dramatically <a href="http://codinginmysleep.com/ultraprune-in-plain-english/" rel="nofollow">changes how it stores and accesses data</a> that will reduce the amount of disk storage space to some degree but also will provide a dramatic increase in performance.</p>

CC BY-SA 3.0
2012-12-19T01:54:30.253Z
Where can I learn about the benefits and design of the new storage system?  Also the configuration (indexes, etc)?
makerofthings7
CC BY-SA 3.0
2012-12-19T02:02:23.957Z
Good to know it's being worked on, but assuming it survives until the year all 21m are mined; this will not stop the blockchain's size growth since transactions depend on the creation of new blocks, right? Storage space will always be limited (despite its getting cheaper) so how is this sustainable when its a snowball getting bigger & bigger?
Deniz
CC BY-SA 3.0
2012-12-19T02:38:59.220Z
From https://en.bitcoin.it/wiki/Scalability : "It is not required for most fully validating nodes to store the entire chain. ... "pruning", a way to delete unnecessary data about transactions that are fully spent. This reduces the amount of data that is needed for a fully validating node to be only the size of the current unspent output size, plus some additional data... As of October 2012 (block 203258) there have been 7,979,231 transactions, however the size of the unspent output set is less than 100MiB, which is small enough to easily fit in RAM for even quite old computers."
Highly Irregular
CC BY-SA 3.0
2012-12-19T02:39:24.590Z
@Deniz, does that help?
Highly Irregular
CC BY-SA 3.0
2012-12-19T03:32:38.010Z
@HighlyIrregular indeed does, thx
Deniz
CC BY-SA 3.0
2012-12-19T05:48:19.130Z
It's also a little disingenuous to use terms like "eating up all available space." That would be a real possibility if hard disks never got bigger or if the growth of the block chain was outpacing the growth rate of hard disk media, but to my knowledge neither of these factors is true.
David Perry
CC BY-SA 3.0
2012-12-19T10:47:13.287Z
@makerofthings7  https://github.com/bitcoin/bitcoin/pull/1677  http://codinginmysleep.com/ultraprune-in-plain-english/
Stephen Gornick
CC BY-SA 3.0
2012-12-20T23:19:24.517Z
Right now, there are some improvements to the storage requirements, but they are hardly dramatic as the full block history is still stored. The new database layout will allow pruned nodes however (which isn't implemented yet, because of concerns about the effect on the network).
Pieter Wuille
CC BY-SA 3.0
2012-12-19T01:23:28.783Z
2012-12-25T12:24:32.153Z
2012-12-25T12:24:32.153Z
Stephen Gornick
<p>Every time the Bitcoin-Qt is launched, the blockchain syncs to update to its latest state. Does this mean the data stored locally will always grow continously, eating up all available space eventually? Or is there a size-limit so that only the latest info is kept? How does it work?</p>

<p>At the time of writing, my folder is 5.82GB; let's see if this changes..</p>

<blockchain><block><synchronization>
Does the synced blockchain always grow in size?
Deniz
# Does the synced blockchain always grow in size?

(Asked by: username_0 on 2012-12-19)

Every time the Bitcoin-Qt is launched, the blockchain syncs to update to its latest state. Does this mean the data stored locally will always grow continously, eating up all available space eventually? Or is there a size-limit so that only the latest info is kept? How does it work?

At the time of writing, my folder is 5.82GB; let's see if this changes..

**Tags:** blockchain, block, synchronization


---

## 1 answers

### Answer by username_1 on 2012-12-19. Score: 7

The Bitcoin.org client v0.7 and lower will continuously increase in size about once every ten minutes, on average.

Blockchain.info provides a [chart](http://blockchain.info/charts/blocks-size) showing the size of the data (actual disk consumption will be slightly larger even.)

The Bitcoin.org client v0.8, being developed now, dramatically [changes how it stores and accesses data](http://codinginmysleep.com/ultraprune-in-plain-english/) that will reduce the amount of disk storage space to some degree but also will provide a dramatic increase in performance.

> **Comments:**
> **username_2**: Where can I learn about the benefits and design of the new storage system?  Also the configuration (indexes, etc)?  
> **username_0**: Good to know it's being worked on, but assuming it survives until the year all 21m are mined; this will not stop the blockchain's size growth since transactions depend on the creation of new blocks, right? Storage space will always be limited (despite its getting cheaper) so how is this sustainable when its a snowball getting bigger & bigger?  
> **username_3**: From https://en.bitcoin.it/wiki/Scalability : "It is not required for most fully validating nodes to store the entire chain. ... "pruning", a way to delete unnecessary data about transactions that are fully spent. This reduces the amount of data that is needed for a fully validating node to be only the size of the current unspent output size, plus some additional data... As of October 2012 (block 203258) there have been 7,979,231 transactions, however the size of the unspent output set is less than 100MiB, which is small enough to easily fit in RAM for even quite old computers."  
> **username_3**: @username_0, does that help?  
> **username_0**: @username_3 indeed does, thx  
> **username_4**: It's also a little disingenuous to use terms like "eating up all available space." That would be a real possibility if hard disks never got bigger or if the growth of the block chain was outpacing the growth rate of hard disk media, but to my knowledge neither of these factors is true.  
> **username_1**: @username_2  https://github.com/bitcoin/bitcoin/pull/1677  http://codinginmysleep.com/ultraprune-in-plain-english/  
> **username_5**: Right now, there are some improvements to the storage requirements, but they are hardly dramatic as the full block history is still stored. The new database layout will allow pruned nodes however (which isn't implemented yet, because of concerns about the effect on the network).  

---

