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.
The key detail people miss: Utreexo doesn't store the UTXO set on the node at all. Instead, proofs are attached to transactions by a 'bridge node' that does maintain the full set. The validating node just needs ~1KB of accumulator state to verify any proof.
The tradeoff: proof attachment adds ~200-400 bytes per input to transaction data. For a typical 2-input transaction, that's an extra ~600 bytes. On-chain impact is why Utreexo works better at the peer protocol layer than in base-layer transactions directly.