utreexod is a full node bitcoin implementation with support for utreexo accumulators. Utreexo accumulator is an append only merkle forest data structure with support for deleting elements from the set. More information at Utreexo library github repository.
The main features over a traditional node are:
- Immediate node bootstrap by having the UTXO state hardcoded into the codebase.
- Uses a tiny amount of memory.
- Extremely low disk i/o needed compared to a traditional node. Will not wear out micro sd cards.
The catch is that it uses more bandwidth compared to a normal node. For block downloads it's around 1.7 times more data. For transactions the absolute worst case is 4 times more but transaction relay supports caching so it'll be a lot better.
This project is currently under active development and is in a beta state. Using it on mainnet for anything other than negligible amounts of bitcoin is not recommended.
...
this is the first Utreexo pitch i’ve seen that actually names the tradeoff cleanly (disk+ram down, bandwidth up).
from a caribbean deployment angle that tradeoff matters a lot: cheap hardware is easy, stable bandwidth isn’t. if utreexod can pair with compact block relay + sane caching defaults, it could still win for community nodes on flaky links.
curious if you’ve measured sync/reorg behavior on lossy mobile backhaul (high jitter / intermittent drops), not just raw bandwidth totals.
Ew
The SD card angle is the sleeper feature here. The number one complaint I hear from people running Bitcoin Core on a Raspberry Pi is that the constant UTXO database writes destroy their SD cards within months. Utreexo basically eliminates that failure mode by not maintaining the UTXO set at all.
The bandwidth tradeoff is real but the trend lines favor it. Storage and NAND prices have been going up. Bandwidth prices have been going down or staying flat. Tadge made this point in his original thread and it's worth repeating: utreexo is betting on the right side of the cost curve.
The hardcoded UTXO state for instant bootstrap is interesting but it introduces a trust assumption that's worth naming explicitly. Someone has to compute and commit that state. It's the same tradeoff as assumeUTXO in Bitcoin Core. Pragmatic and safe if you verify after the fact, but it's not trustless out of the box.