<p>The purpose of a full node is to unilaterally verify that all rules of the Bitcoin protocol have been followed, and to synchronize a node’s state with the global network’s state. Keeping available the entire <em>Unspent Transaction Output set (UTXO set)</em> is both a necessity to that end as well as the end itself: more than anything else, the UTXO set represents the current state of the network.</p>
<p>While pruned nodes can discard blockchain data after processing it, as established in <a href="https://bitcoin.stackexchange.com/a/121851/5406">Why is a bitcoin node pruned to 550MB taking up 10GB+?</a>, the <code>chainstate</code> database stores the UTXO set which cannot be pruned for a full node to fulfill its purpose. Given that your Bitcoin directory appears to be roughly the expected size for a pruned node, and you state that all of the mentioned nodes are pruned, I suspect that the answer is: <em>you cannot further reduce the storage footprint of your pruned nodes without impeding their function.</em> As to why they have different sizes, I suspect that the varying block intervals translate to different minima on how many blocks are retained, and the networks obviously differ in the size of their UTXO sets.</p>
<p>If you do not actually need a fullnode you may be able to replace your fullnodes with third-party data sources or SPV clients, but if you do need the functionality of a fullnode, the reported numbers appear to be the expected minima.</p>

CC BY-SA 4.0
2024-03-13T18:46:49.977Z
2024-03-13T20:41:58.337Z
2024-03-13T20:41:58.337Z
Murch
<p>I have these nodes pruned to their minimum (500MB and 2.2GB for Dogecoin) but as you can see they're still relatively large for their prune size.</p>
<p>How can I reduce their size further?</p>
<pre><code># du -shc /home/bitcoin /home/bitcoinregtest /home/bitcoincash /home/dogecoin /home/litecoin
13G     /home/bitcoin
117M    /home/bitcoinregtest
5.2G    /home/bitcoincash
14G     /home/dogecoin
4.0G    /home/litecoin
35G     total
</code></pre>

CC BY-SA 4.0
2024-03-12T21:10:36.693Z
I was reminded of a question from a month ago, but now I’m confused. The question I was thinking of was your own, where you asked a month ago why a pruned node takes that much space and [learned](https://bitcoin.stackexchange.com/a/121851/5406) that the minimum size of a pruned node is that large due to storing the UTXO set which is necessary for a full node to function. The answer to that question seems entirely applicable to this new question of yours. As Antoine said, the UTXO set cannot be pruned. Could you please elaborate how your new question is not already answered by that topic?
Murch
CC BY-SA 4.0
2024-03-13T18:29:33.127Z
I know they're very similar questions but they're not actually the same and I suspect the other question's answer may be incomplete given the magnitude of disparity I'm seeing (I might be wrong, though). I was hoping given a direct question somebody/somebody else would provide new insight and possible strategies for reducing the size further.
Shovas
<litecoin><bitcoin-cash><pruning><dogecoin><storage-footprint>
How do I reduce the size of these pruned nodes?
Shovas
# How do I reduce the size of these pruned nodes?

(Asked by: username_0 on 2024-03-12)

I have these nodes pruned to their minimum (500MB and 2.2GB for Dogecoin) but as you can see they're still relatively large for their prune size.

How can I reduce their size further?

```
# du -shc /home/bitcoin /home/bitcoinregtest /home/bitcoincash /home/dogecoin /home/litecoin
13G     /home/bitcoin
117M    /home/bitcoinregtest
5.2G    /home/bitcoincash
14G     /home/dogecoin
4.0G    /home/litecoin
35G     total

```

**Tags:** litecoin, bitcoin-cash, pruning, dogecoin, storage-footprint

> **Comments:**
> **username_1**: I was reminded of a question from a month ago, but now I’m confused. The question I was thinking of was your own, where you asked a month ago why a pruned node takes that much space and [learned](https://bitcoin.stackexchange.com/a/121851/5406) that the minimum size of a pruned node is that large due to storing the UTXO set which is necessary for a full node to function. The answer to that question seems entirely applicable to this new question of yours. As Antoine said, the UTXO set cannot be pruned. Could you please elaborate how your new question is not already answered by that topic?  
> **username_0**: I know they're very similar questions but they're not actually the same and I suspect the other question's answer may be incomplete given the magnitude of disparity I'm seeing (I might be wrong, though). I was hoping given a direct question somebody/somebody else would provide new insight and possible strategies for reducing the size further.  

---

## 1 answers

### Answer by username_1 on 2024-03-13. Score: 1

The purpose of a full node is to unilaterally verify that all rules of the Bitcoin protocol have been followed, and to synchronize a node’s state with the global network’s state. Keeping available the entire *Unspent Transaction Output set (UTXO set)* is both a necessity to that end as well as the end itself: more than anything else, the UTXO set represents the current state of the network.

While pruned nodes can discard blockchain data after processing it, as established in [Why is a bitcoin node pruned to 550MB taking up 10GB+?](https://bitcoin.stackexchange.com/a/121851/5406), the `chainstate` database stores the UTXO set which cannot be pruned for a full node to fulfill its purpose. Given that your Bitcoin directory appears to be roughly the expected size for a pruned node, and you state that all of the mentioned nodes are pruned, I suspect that the answer is: *you cannot further reduce the storage footprint of your pruned nodes without impeding their function.* As to why they have different sizes, I suspect that the varying block intervals translate to different minima on how many blocks are retained, and the networks obviously differ in the size of their UTXO sets.

If you do not actually need a fullnode you may be able to replace your fullnodes with third-party data sources or SPV clients, but if you do need the functionality of a fullnode, the reported numbers appear to be the expected minima.


---

