<p>Yes. The growth of the UTXO set size is very important to maintaining low barriers of entry for any newcomer that may want to join the Bitcoin network. If the growth of the UTXO set size was left unchecked, the growth will outstrip the hardware capability of common household computing devices. Even now, it is infeasible to run a Bitcoin node on a mobile phone, but it is a goal nevertheless to be able to run a Bitcoin full node in <em>most</em> if not all computing devices, so the barriers of entry are kept as low as possible.</p>

<blockquote>
  <p>The main motivation cited is reducing block orphaning, which is mining-fullnode-only problem</p>
</blockquote>

<p>Operating a full node is not just for miners.
Every Bitcoin user should run a full node to protect their own privacy. A side effect of that is also maintaining decentralisation by keeping the ratio to non-mining verifiers to mining verifiers high.</p>

<blockquote>
  <p>1) Is there some other reason for research behind UTXO set size other than block-orphaning?</p>
</blockquote>

<p>Block orphaning is not a method to reduce the UTXO set size. In fact, it is an attempt by a miner whether conscientiously or not to orphan a chain, hence producing an orphaned block. (unless I'm not up to date and there's really a technique known as Block Orphaning)</p>

<blockquote>
  <p>2) Directly related to the first question, is the UTXO set size really that important for non-mining full nodes?</p>
</blockquote>

<p>As explained earlier, yes -- the UTXO set size is very important, more so for non-mining validators in fact and also efforts to keep Bitcoin as decentralized as possible.</p>

CC BY-SA 4.0
2018-05-24T16:55:20.230Z
While I'm a big supporter of reducing the UTXO set size, I'm not sure if such size is that big of a deal for lightweight clients, compared to the energy consumption and the requirements of having to process, validate and relay every valid transaction and block. The UTXO set is around 3GB nowadays. A pruned node (550 MiB) may be able to run holding less than 4GB of data.
sr_gi
CC BY-SA 4.0
2018-05-25T05:08:22.123Z
A pruned node still needs full view of the UTXO set and it is a burden for  small processors.
rny
CC BY-SA 4.0
2018-05-25T06:33:24.433Z
@renlord, I meant block orphaning as a consequence large UTXO set. 
large UTXO set ==> longer time to validate blocks for miners ==> More orphans.
sanket1729
CC BY-SA 4.0
2018-05-25T06:49:15.767Z
@renlord, I have edited the question. Making it more clearer
sanket1729
CC BY-SA 4.0
2018-05-24T16:35:31.380Z
2018-05-25T05:10:49.117Z
2018-05-25T05:10:49.117Z
rny
<blockquote>
  <p>The main motivation cited is reducing block orphaning</p>
</blockquote>

<p>Where do you see this being cited?</p>

<p>AFAIK, the motivation is to reduce the resources required to run a full node which has nothing to do with reducing block orphaning. Furthermore, the size of the UTXO set does not really effect block orphaning that much, especially with compact blocks and FIBRE allowing blocks to be relayed without being fully validated.</p>

<blockquote>
  <p>My personal fullnode does not care about if the UTXO is fetched from disk and takes time to verify. (as long it's well under 10 mins)</p>
</blockquote>

<p>Your node does not just need the UTXO set when verifying blocks. It constantly needs it to verify the transactions that it receives. Your node does not just sit idly doing nothing between blocks, it constantly receives transactions, verifies them, and relays them. If access to the UTXO set is slow, then verifying these transactions is also slow. It also means that your computer may be devoting a lot of extra resources in order to try to process transactions quickly which will impact its performance in other tasks if you use your computer for more than just a Bitcoin full node.</p>

<blockquote>
  <p>1) Is there some other reason for research behind UTXO set size other than block-orphaning?</p>
</blockquote>

<p>As mentioned earlier, block orphaning is really unrelated. The main reason is to keep the cost of running a full node down to allow full nodes to be run on as low end hardware as possible (e.g. a raspberry pi) so that there are more nodes. Having more full nodes is better for the network, and keeping the size of the UTXO set small helps allow for lower powered hardware to be used for full nodes.</p>

<blockquote>
  <p>2) Directly related to the first question, is the UTXO set size really that important for non-mining full nodes?</p>
</blockquote>

<p>Yes. All full nodes need the UTXO set in order to validate transactions. If the UTXO set is too large, it becomes more expensive to retrieve data from the UTXO set which thus increases the costs of running a full node.</p>

<p>Presumably you do other things on the computer that runs your full node. You don't want the node to take up all of the resources of your computer, otherwise you wouldn't be able to use it to do other stuff. Part of keeping the node performant is to reduce the size of the UTXO set.</p>

CC BY-SA 4.0
2018-05-25T06:08:57.813Z
2018-05-25T06:08:57.813Z
Ava Chow
<p>Recently, I have seen a lot of development effort going into techniques for different ways of storing, pruning UTXO/TXOs. The main motivation cited is reducing block orphaning, which is <strong><em>mining-fullnode-only</em></strong> problem. My personal fullnode does not care about if the UTXO is fetched from disk and takes time to verify. (as long it's well under 10 mins)</p>

<p>Miners (referring to pool owners who actually run the full node) today are rich people with huge amount of investment costs. Buying extra RAM should be relatively small investment compared to other things. </p>

<p>I understand that bitcoin is a open source project and anyone can work on whatever they like, but I fail to understand the real motivation/need for UTXO set pruning. </p>

<p>1) Is there some other reason for research behind UTXO set size other than preventing block-orphaning (large UTXO set so that it does not fit in RAM ==> longer time to validate blocks for miners ==> More orphans)?</p>

<p>2) Directly related to the first question, is making sure that UTXO set fits in RAM <em>really that</em> important for non-mining full nodes? </p>

<bitcoin-core><development><transaction-verification><utxo-set><cost-of-node-option>
Is the UTXO set size important for non-mining full nodes?
sanket1729
# Is the UTXO set size important for non-mining full nodes?

(Asked by: username_0 on 2018-05-24)

Recently, I have seen a lot of development effort going into techniques for different ways of storing, pruning UTXO/TXOs. The main motivation cited is reducing block orphaning, which is ***mining-fullnode-only*** problem. My personal fullnode does not care about if the UTXO is fetched from disk and takes time to verify. (as long it's well under 10 mins)

Miners (referring to pool owners who actually run the full node) today are rich people with huge amount of investment costs. Buying extra RAM should be relatively small investment compared to other things.

I understand that bitcoin is a open source project and anyone can work on whatever they like, but I fail to understand the real motivation/need for UTXO set pruning.

1) Is there some other reason for research behind UTXO set size other than preventing block-orphaning (large UTXO set so that it does not fit in RAM ==> longer time to validate blocks for miners ==> More orphans)?

2) Directly related to the first question, is making sure that UTXO set fits in RAM *really that* important for non-mining full nodes?

**Tags:** bitcoin-core, development, transaction-verification, utxo-set, cost-of-node-option


---

## 2 answers

### Answer by username_3 on 2018-05-25. Score: 4 | Accepted answer

> The main motivation cited is reducing block orphaning

Where do you see this being cited?

AFAIK, the motivation is to reduce the resources required to run a full node which has nothing to do with reducing block orphaning. Furthermore, the size of the UTXO set does not really effect block orphaning that much, especially with compact blocks and FIBRE allowing blocks to be relayed without being fully validated.

> My personal fullnode does not care about if the UTXO is fetched from disk and takes time to verify. (as long it's well under 10 mins)

Your node does not just need the UTXO set when verifying blocks. It constantly needs it to verify the transactions that it receives. Your node does not just sit idly doing nothing between blocks, it constantly receives transactions, verifies them, and relays them. If access to the UTXO set is slow, then verifying these transactions is also slow. It also means that your computer may be devoting a lot of extra resources in order to try to process transactions quickly which will impact its performance in other tasks if you use your computer for more than just a Bitcoin full node.

> 1) Is there some other reason for research behind UTXO set size other than block-orphaning?

As mentioned earlier, block orphaning is really unrelated. The main reason is to keep the cost of running a full node down to allow full nodes to be run on as low end hardware as possible (e.g. a raspberry pi) so that there are more nodes. Having more full nodes is better for the network, and keeping the size of the UTXO set small helps allow for lower powered hardware to be used for full nodes.

> 2) Directly related to the first question, is the UTXO set size really that important for non-mining full nodes?

Yes. All full nodes need the UTXO set in order to validate transactions. If the UTXO set is too large, it becomes more expensive to retrieve data from the UTXO set which thus increases the costs of running a full node.

Presumably you do other things on the computer that runs your full node. You don't want the node to take up all of the resources of your computer, otherwise you wouldn't be able to use it to do other stuff. Part of keeping the node performant is to reduce the size of the UTXO set.


---

### Answer by username_1 on 2018-05-24. Score: 1

Yes. The growth of the UTXO set size is very important to maintaining low barriers of entry for any newcomer that may want to join the Bitcoin network. If the growth of the UTXO set size was left unchecked, the growth will outstrip the hardware capability of common household computing devices. Even now, it is infeasible to run a Bitcoin node on a mobile phone, but it is a goal nevertheless to be able to run a Bitcoin full node in *most* if not all computing devices, so the barriers of entry are kept as low as possible.

> The main motivation cited is reducing block orphaning, which is mining-fullnode-only problem

Operating a full node is not just for miners.
Every Bitcoin user should run a full node to protect their own privacy. A side effect of that is also maintaining decentralisation by keeping the ratio to non-mining verifiers to mining verifiers high.

> 1) Is there some other reason for research behind UTXO set size other than block-orphaning?

Block orphaning is not a method to reduce the UTXO set size. In fact, it is an attempt by a miner whether conscientiously or not to orphan a chain, hence producing an orphaned block. (unless I'm not up to date and there's really a technique known as Block Orphaning)

> 2) Directly related to the first question, is the UTXO set size really that important for non-mining full nodes?

As explained earlier, yes -- the UTXO set size is very important, more so for non-mining validators in fact and also efforts to keep Bitcoin as decentralized as possible.

> **Comments:**
> **username_2**: While I'm a big supporter of reducing the UTXO set size, I'm not sure if such size is that big of a deal for lightweight clients, compared to the energy consumption and the requirements of having to process, validate and relay every valid transaction and block. The UTXO set is around 3GB nowadays. A pruned node (550 MiB) may be able to run holding less than 4GB of data.  
> **username_1**: A pruned node still needs full view of the UTXO set and it is a burden for  small processors.  
> **username_0**: @renlord, I meant block orphaning as a consequence large UTXO set.  large UTXO set ==> longer time to validate blocks for miners ==> More orphans.  
> **username_0**: @renlord, I have edited the question. Making it more clearer  

---

