<p>My view would be that it isn't currently possible to run a fully validating node on a &quot;normal&quot; computer and that it will be less so in future. However, the stretch from a &quot;normal&quot; computer to a capable system won't necessarily be out of reach either.</p>
<p>Bitcoin has to maintain a &quot;sweet spot&quot; which means nodes don't have to be hugely widespread but do have to be within reach of enough people to establish sufficient decentralisation.</p>
<p>My own peculiar philosophy is that Bitcoin's &quot;limitations&quot; actually underpin it's longevity. On the one hand, its blockchain &quot;limitations&quot; have allowed for continued decentralisation, but have also spawned higher transaction layers that were always going to be necessary for widespread adoption.</p>
<p>The higher &quot;off chain&quot; layers are obviously less secure, but we tolerate lower security for lower value transactions in our current exchange systems, so there's no reason to see this as a limitation.</p>

CC BY-SA 4.0
2021-02-09T22:58:22.623Z
2021-02-09T22:58:22.623Z
Garreth McDaid
<p>Bitcoin has to maintain some balance to be able to retain the ability to be decentralized. As you've correctly established, this is partly down to making sure that the resource requirements of <em>fully validating</em> the block chain are not unreasonable. There's a push form the consumer side of things to constantly increase the resource usage of Bitcoin for convenience or lower transaction fees, but this comes at the cost of decentralization. What the limits for this are is debatable to some extent, but there are clearly hard limits to avoid.</p>
<p>Most notably it's difficult to undo mistakes in this area of the system design, going too far with resource usage is effectively a permanent decision so you will find that choices have been made as conservative as reasonable.</p>
<p>We have the following limitations to contend with:</p>
<ul>
<li><p><strong>Size of the block chain.</strong> It is often advantageous to store previously validated information, even if it is not immediately required for the operation of the system. It makes wallet management easier and allows for easy re-synchronization if required. The limit of this can not be above reasonable cost or the size of volumes available to the mass-market.</p>
<p>Growth of the block chain size on dish currently is bounded by the block size limit. Knowing that 6 blocks happen on average per hour, and they can be a maximum of 4MiB when fully saturated with Segwit transactions, we have a bounded growth of 210 GiB per year.</p>
</li>
</ul>
<p>Nodes can disgard these blocks once validated to avoid storing them, but the entire set must be transmitted to them in some form, typically over the internet but could be done via Bluray, Fedex, or carrier pigeon if this was cheaper or required. This is a limit for the size of the growth, as it must not exceed the ability of users to obtain the data needed to validate.</p>
<ul>
<li><p><strong>Size of the UTXO.</strong> The Unspent Transaction Outputs database is the storage of units of Bitcoin that have not been spent. This is consensus critical and must be stored by all nodes in the network who are fully validating. This database has looser restrictions on its growth, and is effectively bounded by the block size as well, as it implicitly limits the number of entries which can be added to the database. Unfortunately there is not much to be done to reduce the impact of this 4 GiB storage on disk without much larger economic changes to Bitcoin to allow for entries to be &quot;archived&quot;.</p>
</li>
<li><p><strong>Validation complexity.</strong> The transactions within the chain have a cost associated with their validation. ECDSA is used in Bitcoin due to it being extremely space efficient and suitable for the task, but it is not particularly fast even with completely optimized implementations. Synchronizing the Bitcoin chain involves billions of individual SHA256 and ECDSA operations which puts a hard limit on the number which can be performed by a consumer processor in a reasonable amount of time. The growth of the chain should not exceed the ability for reasonable, consumer hardware to complete validation.</p>
</li>
</ul>

CC BY-SA 4.0
2019-10-05T16:09:52.847Z
2021-02-08T18:46:48.650Z
2021-02-08T18:46:48.650Z
Claris
<p>I am a Bitcoin enthusiast, with no background knowledge in computer science and cryptography. I once ran Bitcoin Core on my laptop but realized that it occupied too much space on my computer.</p>
<p>I understand the idea that Bitcoin network is secure as long as any individual can run the full node of Bitcoin Core. However, what concerns me is that one day the full node may become too large to run on a normal computer. Do Bitcoin developers have any solutions to this problem? Or is it really a problem?</p>
<p>I would like to hear some responses from cryptocurrency developers or specialists in computer science.</p>

CC BY-SA 4.0
2021-02-08T19:05:07.257Z
I've removed several comments discussing a pseudo-answer to the question. Please post answers as answer posts.
Murch
<bitcoin-core><full-node><block-size-increase><storage-footprint><cost-of-node-option>
Will the size of a Bitcoin Core full node be too big to run on a normal computer?
Xenomorph
# Will the size of a Bitcoin Core full node be too big to run on a normal computer?

(Asked by: username_0 on 2019-10-05)

I am a Bitcoin enthusiast, with no background knowledge in computer science and cryptography. I once ran Bitcoin Core on my laptop but realized that it occupied too much space on my computer.

I understand the idea that Bitcoin network is secure as long as any individual can run the full node of Bitcoin Core. However, what concerns me is that one day the full node may become too large to run on a normal computer. Do Bitcoin developers have any solutions to this problem? Or is it really a problem?

I would like to hear some responses from cryptocurrency developers or specialists in computer science.

**Tags:** bitcoin-core, full-node, block-size-increase, storage-footprint, cost-of-node-option

> **Comments:**
> **username_1**: I've removed several comments discussing a pseudo-answer to the question. Please post answers as answer posts.  

---

## 2 answers

### Answer by username_3 on 2019-10-05. Score: 15 | Accepted answer

Bitcoin has to maintain some balance to be able to retain the ability to be decentralized. As you've correctly established, this is partly down to making sure that the resource requirements of *fully validating* the block chain are not unreasonable. There's a push form the consumer side of things to constantly increase the resource usage of Bitcoin for convenience or lower transaction fees, but this comes at the cost of decentralization. What the limits for this are is debatable to some extent, but there are clearly hard limits to avoid.

Most notably it's difficult to undo mistakes in this area of the system design, going too far with resource usage is effectively a permanent decision so you will find that choices have been made as conservative as reasonable.

We have the following limitations to contend with:

* **Size of the block chain.** It is often advantageous to store previously validated information, even if it is not immediately required for the operation of the system. It makes wallet management easier and allows for easy re-synchronization if required. The limit of this can not be above reasonable cost or the size of volumes available to the mass-market.

  Growth of the block chain size on dish currently is bounded by the block size limit. Knowing that 6 blocks happen on average per hour, and they can be a maximum of 4MiB when fully saturated with Segwit transactions, we have a bounded growth of 210 GiB per year.

Nodes can disgard these blocks once validated to avoid storing them, but the entire set must be transmitted to them in some form, typically over the internet but could be done via Bluray, Fedex, or carrier pigeon if this was cheaper or required. This is a limit for the size of the growth, as it must not exceed the ability of users to obtain the data needed to validate.

* **Size of the UTXO.** The Unspent Transaction Outputs database is the storage of units of Bitcoin that have not been spent. This is consensus critical and must be stored by all nodes in the network who are fully validating. This database has looser restrictions on its growth, and is effectively bounded by the block size as well, as it implicitly limits the number of entries which can be added to the database. Unfortunately there is not much to be done to reduce the impact of this 4 GiB storage on disk without much larger economic changes to Bitcoin to allow for entries to be "archived".
* **Validation complexity.** The transactions within the chain have a cost associated with their validation. ECDSA is used in Bitcoin due to it being extremely space efficient and suitable for the task, but it is not particularly fast even with completely optimized implementations. Synchronizing the Bitcoin chain involves billions of individual SHA256 and ECDSA operations which puts a hard limit on the number which can be performed by a consumer processor in a reasonable amount of time. The growth of the chain should not exceed the ability for reasonable, consumer hardware to complete validation.


---

### Answer by username_2 on 2021-02-09. Score: 0

My view would be that it isn't currently possible to run a fully validating node on a "normal" computer and that it will be less so in future. However, the stretch from a "normal" computer to a capable system won't necessarily be out of reach either.

Bitcoin has to maintain a "sweet spot" which means nodes don't have to be hugely widespread but do have to be within reach of enough people to establish sufficient decentralisation.

My own peculiar philosophy is that Bitcoin's "limitations" actually underpin it's longevity. On the one hand, its blockchain "limitations" have allowed for continued decentralisation, but have also spawned higher transaction layers that were always going to be necessary for widespread adoption.

The higher "off chain" layers are obviously less secure, but we tolerate lower security for lower value transactions in our current exchange systems, so there's no reason to see this as a limitation.


---

