Inspired by the discussion on this question, I wonder what the downsides would be of adding accumulators like Utreexo (site, paper) 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.

  • 2
    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? Commented Jul 14, 2019 at 0:03
  • 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. Commented Jul 14, 2019 at 6:52

2 Answers 2


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, 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).


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!


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.