<p>Utreexo is not about not storing the history of transactions, it's about compressing the UTXO set. However this can allow pruned nodes to have even less storage requirements (the UTXO set they currently need to store is a couple of GB, while the Utreexo state is less than a kb).</p>
<p>With Utreexo, the UTXO set is represented as a bunch of merkle roots that are updated after each Bitcoin block (some UTXOs are deleted and others are added). Importantly we are eliminating I/O operations because UTXO operations can happen on memory.</p>
<p>The tradeoff is that nodes keeping track of the Utreexo state need inclusion proofs in order to validate each block (and this increases bandwidth costs for Utreexo nodes). With <a href="https://fc21.ifca.ai/wtsc/WTSC21paper8.pdf" rel="nofollow noreferrer">optimizations</a>, the proofs per block are about 250kb. Also there must be bridge nodes (a kind of archival node) that serve inclusion proofs along with the UTXOs being spent for each block in history, so that a new Utreexo node can perform IBD (without keeping the large UTXO database).</p>

CC BY-SA 4.0
2023-02-12T18:41:09.313Z
2023-02-12T18:41:09.313Z
Son Kaos999
<p>Utreexo makes it possible to use Bitcoin securely without downloading the full blockchain. Since some prominent Bitcoin Core devs think there are not enough full nodes, I speculate that some may not like the prospect of less full nodes (less decentralization), and further more, more code complexity.</p>

<p>Also, Utreexo is still in development.</p>

<p>Also, since it requires no forks, so there is no pressure to integrate it into Bitcoin Core. With so many alternative wallets, a developer really has little incentive to work with the Core community when he could get it merged into a another wallet (his own :P) with certainty.</p>

<p>Take BIP 157/158 as an example. We all know code review is great, but I speculate that many developers would be discouraged from the amount of effort it takes to get something merged. If you have another wallet, as roasbeef does (btcd), I can't blame him for not wanting to bother with bikeshedding a Core PR for months, leaving it up to Jim Posen to see this through.</p>

<p>I speculate that Utreexo only exists because Tadge realized that the only way to get something like this is by doing it in a way that requires no changes to Core. There have been many UTXO-commitment-related proposals, for example Bram Cohen's proposal, which is arguably way simpler, but was too radical a change. Now the man is starting his own coin.</p>

<p>Learn to just appreciate the fact that Core is getting more and more stable!</p>

CC BY-SA 4.0
2020-12-28T14:30:05.420Z
With UTreeXO you "still need to download everything". see: https://twitter.com/tdryja/status/1285987606195470344
Chris Chen
CC BY-SA 4.0
2019-10-13T18:50:33.197Z
2019-10-13T18:50:33.197Z
Janus Troelsen
<p>Inspired by the discussion on this <a href="https://bitcoin.stackexchange.com/a/89019/81940">question</a>, I wonder what the downsides would be of adding accumulators like Utreexo (<a href="https://dci.mit.edu/utreexo" rel="nofollow noreferrer">site</a>, <a href="https://eprint.iacr.org/2019/611.pdf" rel="nofollow noreferrer">paper</a>) to bitcoind?</p>
<p>On the positive side, it seems like a huge improvement if we don't need to store the history of all transactions but rather rely on merkle proofs.</p>

CC BY-SA 4.0
2019-07-14T00:03:25.990Z
Do you mean adding it to the *Bitcoin Core* software, as an optional means of syncing faster using a third party service that provides you proofs, or do you mean adding it to *Bitcoin* in the form of P2P protocol/infrastructure or even consensus rules?
Pieter Wuille
CC BY-SA 4.0
2019-07-14T06:52:00.450Z
When asking the question I had the first n mind since that was the obvious step to me but the later seems to me even cooler / more powerful if possible.
Rene Pickhardt
<bitcoin-core-development><synchronization><scalability><utreexo>
What are the downsides of integrating accumulators like Utreexo to bitcoind?
Rene Pickhardt
# What are the downsides of integrating accumulators like Utreexo to bitcoind?

(Asked by: username_0 on 2019-07-13)

Inspired by the discussion on this [question](https://bitcoin.stackexchange.com/a/89019/81940), I wonder what the downsides would be of adding accumulators like Utreexo ([site](https://dci.mit.edu/utreexo), [paper](https://eprint.iacr.org/2019/611.pdf)) to bitcoind?

On the positive side, it seems like a huge improvement if we don't need to store the history of all transactions but rather rely on merkle proofs.

**Tags:** bitcoin-core-development, synchronization, scalability, utreexo

> **Comments:**
> **username_1**: Do you mean adding it to the *Bitcoin Core* software, as an optional means of syncing faster using a third party service that provides you proofs, or do you mean adding it to *Bitcoin* in the form of P2P protocol/infrastructure or even consensus rules?  
> **username_0**: When asking the question I had the first n mind since that was the obvious step to me but the later seems to me even cooler / more powerful if possible.  

---

## 2 answers

### Answer by username_2 on 2023-02-12. Score: 1

Utreexo is not about not storing the history of transactions, it's about compressing the UTXO set. However this can allow pruned nodes to have even less storage requirements (the UTXO set they currently need to store is a couple of GB, while the Utreexo state is less than a kb).

With Utreexo, the UTXO set is represented as a bunch of merkle roots that are updated after each Bitcoin block (some UTXOs are deleted and others are added). Importantly we are eliminating I/O operations because UTXO operations can happen on memory.

The tradeoff is that nodes keeping track of the Utreexo state need inclusion proofs in order to validate each block (and this increases bandwidth costs for Utreexo nodes). With [optimizations](https://fc21.ifca.ai/wtsc/WTSC21paper8.pdf), the proofs per block are about 250kb. Also there must be bridge nodes (a kind of archival node) that serve inclusion proofs along with the UTXOs being spent for each block in history, so that a new Utreexo node can perform IBD (without keeping the large UTXO database).


---

### Answer by username_3 on 2019-10-13. Score: -2

Utreexo makes it possible to use Bitcoin securely without downloading the full blockchain. Since some prominent Bitcoin Core devs think there are not enough full nodes, I speculate that some may not like the prospect of less full nodes (less decentralization), and further more, more code complexity.

Also, Utreexo is still in development.

Also, since it requires no forks, so there is no pressure to integrate it into Bitcoin Core. With so many alternative wallets, a developer really has little incentive to work with the Core community when he could get it merged into a another wallet (his own :P) with certainty.

Take BIP 157/158 as an example. We all know code review is great, but I speculate that many developers would be discouraged from the amount of effort it takes to get something merged. If you have another wallet, as roasbeef does (btcd), I can't blame him for not wanting to bother with bikeshedding a Core PR for months, leaving it up to Jim Posen to see this through.

I speculate that Utreexo only exists because Tadge realized that the only way to get something like this is by doing it in a way that requires no changes to Core. There have been many UTXO-commitment-related proposals, for example Bram Cohen's proposal, which is arguably way simpler, but was too radical a change. Now the man is starting his own coin.

Learn to just appreciate the fact that Core is getting more and more stable!

> **Comments:**
> **username_4**: With UTreeXO you "still need to download everything". see: https://twitter.com/tdryja/status/1285987606195470344  

---

