<p>No, this isn't a likely problem for Bitcoin. Or, to be more specific, it is a problem that there known ways to solve. </p>

<p>First of all, there is a concept called a selfish client. Which means a client that can create and receive transactions, but doesn't maintain the blockchain. It's considered "selfish" because it isn't performing the work expected of a true node on the system: it only maintains the information needed for it's own transactions. These types of clients are already common in the mobile world today, where 8GB is already too much to handle.</p>

<p>But if we got to a scenario where the blockchain was too unwieldy for the typical client, we would also probably be in a scenario where the network already had a sufficient number of server nodes to handle the "network".</p>

<p>Second, Bitcoin already has the concept of discarding transactions once they are spent. (It is made possible by the way that transactions are stored in the block: via the Merkle tree.) It is essentially not implemented yet, but the concept is there for when it is needed.</p>

<p>It's not inconceivable that we might end up with three tiers of clients: selfish clients on our mobile devices, master nodes that have all of the transactions and can trace any transaction ever made, and hybrid nodes that do support the entire Bitcoin protocol but only keep a trimmed version of the blockchain that prunes transactions that have already been spent. See this question for some details about pruning : <a href="https://bitcoin.stackexchange.com/questions/2983/is-pruning-transaction-history-implemented-in-satoshis-bitcoin-client">Is pruning transaction history implemented in Satoshi&#39;s bitcoin client?</a> .</p>

CC BY-SA 3.0
2013-04-03T15:15:22.690Z
I lament that I have but one upvote to give this stellar answer.
Colin Dean
CC BY-SA 3.0
2013-04-03T15:20:35.767Z
I thought this had been answered before, but I couldn't find the duplicate. Thanks for the kind words.
David Ogren
CC BY-SA 3.0
2013-04-03T14:27:40.303Z
2013-04-03T15:21:26.270Z
2017-04-13T12:47:33.610Z
David Ogren
<p><a href="http://www.forbes.com/sites/timothylee/2013/04/03/four-reason-you-shouldnt-buy-bitcoins/" rel="noreferrer"><em>Four Reasons You Shouldn't Buy Bitcoins</em>, Forbes.com:</a></p>

<blockquote>
  <p><strong>Scaling.</strong> The Bitcoin protocol requires that every node in the network
  download a copy of every Bitcoin transaction that has ever occurred.
  As Bitcoin has grown more popular, running the “full” Bitcoin client
  has become more and more resource-intensive. The last time I started
  up my Bitcoin client, it took several hours to download all the
  transactions that had occurred in the few weeks since the last time I
  ran it.</p>
  
  <p>To prevent things from becoming completely unwieldy, the Bitcoin
  protocol limits the size of each “block,” the basic unit of Bitcoin’s
  shared transaction register, to one megabyte. Since one block is
  created every 10 minutes, on average, this places a hard limit on the
  number of transactions the network can process each hour. Right now,
  the network is operating well below the limit. But it’s not that far
  below the limit. If the Bitcoin economy continues to grow rapidly,
  we’re likely to hit it in the next few years.</p>
  
  <p>Reaching the limit wouldn’t be catastrophic; the Bitcoin protocol has
  an elegant system of transaction fees to process the most urgent
  transactions first. But it does place some limits on Bitcoin’s
  long-term future. For example, it’s hard to imagine Bitcoin ever
  becoming a replacement for conventional credit cards. There are far
  too many credit card transactions for the Bitcoin network to
  accomodate.</p>
</blockquote>

<p>Currently, every Bitcoin client knows the entire network history. This sums up to a few GB, which a modern computer can easily hold.</p>

<p>The number of transactions, however, is growing quickly. I roughly estimate than in a matter of a year or two, the total size on disk will exceed the abilities of a normal desktop computer.</p>

<p>How will the network function when the transaction history log grows beyond the powers of a normal desktop?</p>

<transactions><bitcoin-core>
Can the transaction log history size scale?
Adam Matan
# Can the transaction log history size scale?

(Asked by: username_0 on 2013-04-03)

[*Four Reasons You Shouldn't Buy Bitcoins*, Forbes.com:](http://www.forbes.com/sites/timothylee/2013/04/03/four-reason-you-shouldnt-buy-bitcoins/)

> **Scaling.** The Bitcoin protocol requires that every node in the network
> download a copy of every Bitcoin transaction that has ever occurred.
> As Bitcoin has grown more popular, running the “full” Bitcoin client
> has become more and more resource-intensive. The last time I started
> up my Bitcoin client, it took several hours to download all the
> transactions that had occurred in the few weeks since the last time I
> ran it.
>
> To prevent things from becoming completely unwieldy, the Bitcoin
> protocol limits the size of each “block,” the basic unit of Bitcoin’s
> shared transaction register, to one megabyte. Since one block is
> created every 10 minutes, on average, this places a hard limit on the
> number of transactions the network can process each hour. Right now,
> the network is operating well below the limit. But it’s not that far
> below the limit. If the Bitcoin economy continues to grow rapidly,
> we’re likely to hit it in the next few years.
>
> Reaching the limit wouldn’t be catastrophic; the Bitcoin protocol has
> an elegant system of transaction fees to process the most urgent
> transactions first. But it does place some limits on Bitcoin’s
> long-term future. For example, it’s hard to imagine Bitcoin ever
> becoming a replacement for conventional credit cards. There are far
> too many credit card transactions for the Bitcoin network to
> accomodate.

Currently, every Bitcoin client knows the entire network history. This sums up to a few GB, which a modern computer can easily hold.

The number of transactions, however, is growing quickly. I roughly estimate than in a matter of a year or two, the total size on disk will exceed the abilities of a normal desktop computer.

How will the network function when the transaction history log grows beyond the powers of a normal desktop?

**Tags:** transactions, bitcoin-core


---

## 1 answers

### Answer by username_1 on 2013-04-03. Score: 7 | Accepted answer

No, this isn't a likely problem for Bitcoin. Or, to be more specific, it is a problem that there known ways to solve.

First of all, there is a concept called a selfish client. Which means a client that can create and receive transactions, but doesn't maintain the blockchain. It's considered "selfish" because it isn't performing the work expected of a true node on the system: it only maintains the information needed for it's own transactions. These types of clients are already common in the mobile world today, where 8GB is already too much to handle.

But if we got to a scenario where the blockchain was too unwieldy for the typical client, we would also probably be in a scenario where the network already had a sufficient number of server nodes to handle the "network".

Second, Bitcoin already has the concept of discarding transactions once they are spent. (It is made possible by the way that transactions are stored in the block: via the Merkle tree.) It is essentially not implemented yet, but the concept is there for when it is needed.

It's not inconceivable that we might end up with three tiers of clients: selfish clients on our mobile devices, master nodes that have all of the transactions and can trace any transaction ever made, and hybrid nodes that do support the entire Bitcoin protocol but only keep a trimmed version of the blockchain that prunes transactions that have already been spent. See this question for some details about pruning : [Is pruning transaction history implemented in Satoshi's bitcoin client?](https://bitcoin.stackexchange.com/questions/2983/is-pruning-transaction-history-implemented-in-satoshis-bitcoin-client) .

> **Comments:**
> **username_2**: I lament that I have but one upvote to give this stellar answer.  
> **username_1**: I thought this had been answered before, but I couldn't find the duplicate. Thanks for the kind words.  

---

