<p>The main bottleneck of committing to a UTXO merkle root is that it's I/O and CPU heavy to create and verify. As of today the serialized UTXO set is <a href="http://statoshi.info/dashboard/db/unspent-transaction-output-set" rel="noreferrer">around 1GB and it contains almost 34000000 entries</a> and it keeps growing. This means that a naive implementation would have to hash at least that amount of data per block plus the intermediate nodes to construct a merkle tree. This is O(n) complexity and it is generally considered poor performance. It is possible to use caching optimizations but that would use more RAM.</p>

<p>One possible alternative are UTXO differences that each block introduces. It works by committing a merkle root with all the UTXOs that were spent in the current block and another root that lists all the added UTXOs. For an SPV client this could work as a fraud proof, where it is possible to show that a specific output was spent on a specific height (although it is already possible to show it using ordinary transactions).</p>

<p>So to sum up, a full UTXO merkle root commitments are really useful but cannot be used due to poor scaling.</p>

CC BY-SA 3.0
2016-02-02T17:31:06.140Z
How long does it take to calculate a new UTXO merkle root?
Amin
CC BY-SA 3.0
2016-02-02T18:43:22.783Z
Not sure but you need to hash about 2x34 million entries. You can try the `gettxoutsetinfo` rpc command to get a very rough idea (the hash_serialized is the hash of the data, not a UTXO merkle tree).
John L. Jegutanis
CC BY-SA 3.0
2016-01-26T14:47:03.157Z
2016-01-26T17:03:00.250Z
2016-01-26T17:03:00.250Z
John L. Jegutanis
<p>Commits of the UTXO set in the block header would enable more secure lightweight clients and caps on the number of blocks that need to be downloaded and validated in the Initial Blockchain Download, which is vitally important for Bitcoin's longevity and scalability, but I have been told UTXO commits are a very technically challenging change in Bitcoin's design.</p>

<p>What are main technical challenges in implementation of UTXO commitments, and what are the proposed solutions for them?</p>

CC BY-SA 3.0
2015-09-06T15:04:35.990Z
How is this different than checkpoints? CS isn't my forté
Wizard Of Ozzie
CC BY-SA 3.0
2015-09-08T22:29:12.070Z
A UTXO commitment is validated by all of the proof of work that was built on top of it.
Amin
<utxo><spv>
What are the main technical hurdles to implementing UTXO commitments?
Amin
# What are the main technical hurdles to implementing UTXO commitments?

(Asked by: username_0 on 2015-09-05)

Commits of the UTXO set in the block header would enable more secure lightweight clients and caps on the number of blocks that need to be downloaded and validated in the Initial Blockchain Download, which is vitally important for Bitcoin's longevity and scalability, but I have been told UTXO commits are a very technically challenging change in Bitcoin's design.

What are main technical challenges in implementation of UTXO commitments, and what are the proposed solutions for them?

**Tags:** utxo, spv

> **Comments:**
> **username_1**: How is this different than checkpoints? CS isn't my forté  
> **username_0**: A UTXO commitment is validated by all of the proof of work that was built on top of it.  

---

## 1 answers

### Answer by username_2 on 2016-01-26. Score: 5

The main bottleneck of committing to a UTXO merkle root is that it's I/O and CPU heavy to create and verify. As of today the serialized UTXO set is [around 1GB and it contains almost 34000000 entries](http://statoshi.info/dashboard/db/unspent-transaction-output-set) and it keeps growing. This means that a naive implementation would have to hash at least that amount of data per block plus the intermediate nodes to construct a merkle tree. This is O(n) complexity and it is generally considered poor performance. It is possible to use caching optimizations but that would use more RAM.

One possible alternative are UTXO differences that each block introduces. It works by committing a merkle root with all the UTXOs that were spent in the current block and another root that lists all the added UTXOs. For an SPV client this could work as a fraud proof, where it is possible to show that a specific output was spent on a specific height (although it is already possible to show it using ordinary transactions).

So to sum up, a full UTXO merkle root commitments are really useful but cannot be used due to poor scaling.

> **Comments:**
> **username_0**: How long does it take to calculate a new UTXO merkle root?  
> **username_2**: Not sure but you need to hash about 2x34 million entries. You can try the `gettxoutsetinfo` rpc command to get a very rough idea (the hash_serialized is the hash of the data, not a UTXO merkle tree).  

---

