Bitcoin Stack Exchange is a question and answer site for Bitcoin crypto-currency enthusiasts. It only takes a minute to sign up.
Sign up to join this community
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?
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 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.
gettxoutsetinfo rpc command to get a very rough idea (the hash_serialized is the hash of the data, not a UTXO merkle tree).
Feb 2, 2016 at 18:43