<p>It <em>IS</em> a problem - the synchronization time and size of the blockchain is too long and large, respectively.</p>

<p>But for many other business it may be OK because not too many transactions.</p>

<p>There needs to be a solution for bitcoin, blockchain size and synchronization times. It's the main reason I do not use bitcoin.  </p>

CC BY-SA 3.0
2015-11-06T14:34:34.773Z
This answer only addresses a small part of the question, i.e. whether there is a problem. However, it doesn't explore any solutions or explain why the problem isn't severe as the asker requested. Therefore, I don't find it helpful to this question and have downvoted it. Please elaborate and answer the whole question, so that I may turn my downvote into an upvote instead.
Murch
CC BY-SA 3.0
2015-11-06T07:53:53.557Z
2015-11-06T14:31:49.217Z
2015-11-06T14:31:49.217Z
steve1234
<p>Currently, only full-nodes, i.e. nodes that have the complete blockchain inventorized relay blocks. Personally, I've recently encountered the first problem, when my Linux partition ran out of storage, yet if I had chosen a bigger partition size, I'd be able to even afford a multiple of the 50GiB easily.</p>

<ul>
<li><p><strong>Storage usage:</strong> Currently, the blockchain is about 50GiB. If it continues to grow at 1MiB per 10 minutes, storing the complete blockchain should remain affordable for those that want to.<br>
For all the others, there now exists the option to run a <a href="https://bitcoin.stackexchange.com/q/37496/5406">pruning node</a>. <a href="https://github.com/bitcoin/bitcoin/pull/6148" rel="nofollow noreferrer">Once pruning nodes will be enabled to relay blocks</a>, I would expect that the number of serving nodes will start to climb again.<br>
There would need to be some nodes with the complete blockchain to secure history, though.</p></li>
<li><p><strong>Client startup time</strong>: This may become a problem at some point, but the blockchain data doesn't get checked every start-up, rather synchronization only runs once for each block. So, with a current computer, I don't think it is an issue now or in the foreseeable future.</p></li>
<li><p><strong>First-time synchronization</strong>: Synchronization has been dramatically improved with the release of Bitcoin Core 0.10. Now, only the block headers have to be processed in order and all other block data may be processed in any order. This and other tweaks have drastically reduced the time necessary to catch up with the network. My computer can now do initial synchronization within a few hours. As processing power will scale, I expect this to remain manageable for the foreseeable future.<br>
Update: The coming 0.12 release will additionally increase synchronization speed by x5, due to validation of signatures being run through <code>libsecp256k1</code>, a library that has been specifically coded to run Bitcoin operations more efficiently.</p></li>
</ul>

CC BY-SA 3.0
2015-07-26T11:59:37.823Z
2016-01-24T08:32:08.690Z
2017-04-13T12:47:33.283Z
Murch
<p>As more and more Bitcoin transactions are produced, the growth of the Blockchain may well, one day, become a problem for systems which want (need?) to store the whole blockchain.</p>

<ul>
<li>Storage usage</li>
<li>Client startup time</li>
<li>First-time synchronisation</li>
</ul>

<p><a href="https://bitcoin.stackexchange.com/a/8737/822">This answer to "Are there any studies into the size of the blockchain scaling over time?"</a> suggests that Simplified Payment Verification is a good solution, but SPV, as far as I understand it, requires a degree of trust in individual peers that may not be to everyone's taste. </p>

<p>Although I don't really understand the blockchain well enough even to know if this is sensible, the sort of thing that occurs to me might be a mixture of SPV with partial blockchain caching (least frequently used?), where the client keeps a small piece of the blockchain. </p>

<p>Is this really a problem, and is there any work in progress to solve it? </p>

<p>Alternatively, if this isn't a problem, please help me to understand why.</p>

CC BY-SA 3.0
2015-07-24T12:16:35.650Z
Hi Brent, 
Actually, just this issue is currently a hotly debated topic. A little while back, Bitcoin Core added support for [blockchain pruning](http://bitcoin.stackexchange.com/q/37496/5406), which enables node operators to limit the memory available for blockchain storage. However, then the node will not "store the whole blockchain". Longterm solutions are still in development.
Murch
CC BY-SA 3.0
2015-07-24T12:53:48.533Z
@Murch : Thank you - if you'd care to make this an answer, I'd certainly upvote it, and, after a few days, even accept it!
Brent.Longborough
CC BY-SA 3.0
2015-07-24T13:18:53.433Z
Sorry, currently at work. I'll have a look later, to write something more encompassing though.
Murch
CC BY-SA 3.0
2015-07-24T17:00:47.653Z
@Murch : No problem :) It occurs to me that one might run one's own pruned blockchain node (without a wallet, of course), and assign that as a trusted node for an SPV client.
Brent.Longborough
<blockchain><scalability><storage><blocksize>
Is there a (potential) "Blockchain size problem", and what solutions are available?
Brent.Longborough
# Is there a (potential) "Blockchain size problem", and what solutions are available?

(Asked by: username_0 on 2015-07-24)

As more and more Bitcoin transactions are produced, the growth of the Blockchain may well, one day, become a problem for systems which want (need?) to store the whole blockchain.

* Storage usage
* Client startup time
* First-time synchronisation

[This answer to "Are there any studies into the size of the blockchain scaling over time?"](https://bitcoin.stackexchange.com/a/8737/822) suggests that Simplified Payment Verification is a good solution, but SPV, as far as I understand it, requires a degree of trust in individual peers that may not be to everyone's taste.

Although I don't really understand the blockchain well enough even to know if this is sensible, the sort of thing that occurs to me might be a mixture of SPV with partial blockchain caching (least frequently used?), where the client keeps a small piece of the blockchain.

Is this really a problem, and is there any work in progress to solve it?

Alternatively, if this isn't a problem, please help me to understand why.

**Tags:** blockchain, scalability, storage, blocksize

> **Comments:**
> **username_1**: Hi Brent,  Actually, just this issue is currently a hotly debated topic. A little while back, Bitcoin Core added support for [blockchain pruning](http://bitcoin.stackexchange.com/q/37496/5406), which enables node operators to limit the memory available for blockchain storage. However, then the node will not "store the whole blockchain". Longterm solutions are still in development.  
> **username_0**: @username_1 : Thank you - if you'd care to make this an answer, I'd certainly upvote it, and, after a few days, even accept it!  
> **username_1**: Sorry, currently at work. I'll have a look later, to write something more encompassing though.  
> **username_0**: @username_1 : No problem :) It occurs to me that one might run one's own pruned blockchain node (without a wallet, of course), and assign that as a trusted node for an SPV client.  

---

## 2 answers

### Answer by username_1 on 2015-07-26. Score: 4 | Accepted answer

Currently, only full-nodes, i.e. nodes that have the complete blockchain inventorized relay blocks. Personally, I've recently encountered the first problem, when my Linux partition ran out of storage, yet if I had chosen a bigger partition size, I'd be able to even afford a multiple of the 50GiB easily.

* **Storage usage:** Currently, the blockchain is about 50GiB. If it continues to grow at 1MiB per 10 minutes, storing the complete blockchain should remain affordable for those that want to.  
  For all the others, there now exists the option to run a [pruning node](https://bitcoin.stackexchange.com/q/37496/5406). [Once pruning nodes will be enabled to relay blocks](https://github.com/bitcoin/bitcoin/pull/6148), I would expect that the number of serving nodes will start to climb again.  
  There would need to be some nodes with the complete blockchain to secure history, though.
* **Client startup time**: This may become a problem at some point, but the blockchain data doesn't get checked every start-up, rather synchronization only runs once for each block. So, with a current computer, I don't think it is an issue now or in the foreseeable future.
* **First-time synchronization**: Synchronization has been dramatically improved with the release of Bitcoin Core 0.10. Now, only the block headers have to be processed in order and all other block data may be processed in any order. This and other tweaks have drastically reduced the time necessary to catch up with the network. My computer can now do initial synchronization within a few hours. As processing power will scale, I expect this to remain manageable for the foreseeable future.  
  Update: The coming 0.12 release will additionally increase synchronization speed by x5, due to validation of signatures being run through `libsecp256k1`, a library that has been specifically coded to run Bitcoin operations more efficiently.


---

### Answer by username_2 on 2015-11-06. Score: -1

It *IS* a problem - the synchronization time and size of the blockchain is too long and large, respectively.

But for many other business it may be OK because not too many transactions.

There needs to be a solution for bitcoin, blockchain size and synchronization times. It's the main reason I do not use bitcoin.

> **Comments:**
> **username_1**: This answer only addresses a small part of the question, i.e. whether there is a problem. However, it doesn't explore any solutions or explain why the problem isn't severe as the asker requested. Therefore, I don't find it helpful to this question and have downvoted it. Please elaborate and answer the whole question, so that I may turn my downvote into an upvote instead.  

---

