I don’t think the utxo bloat is as big a deal as it’s made out to be. In my way of thinking… you’re admitting that Bitcoin has a bad design if you think it is a big deal.

During initial block download the loading and unloading of the utxo set from the hard drive is becoming trivial. Segwit and Taproot have now made verification of the chain more cpu intensive. If you think utxo bloat is a very big deal then I think you need to consider those two changes as being bad decisions for Bitcoin. They will save you storage and keep the full size of the blockchain data smaller in exchange for increased cpu usage. I think that is a bigger deal than storage space.

If you’re running a public node or a private node for a business and you need to be able to process/query LOTS of transactions then maybe storing the full utxo set in ram will be beneficial. If you’re running a personal node then I don’t think running the full utxo set in ram is necessary.

What you’re basically looking for is a shortcut, skipping proof of work for the node… i.e. checkpoints. There are several already included in Bitcoin Core.

Have you looked into this project? It’s doing a shortcut on the utxo set to bootstrap IBD.

https://bitcoinops.org/en/topics/utreexo/

Also the project led by Eric Voskuil, libbitcoin, is a full Bitcoin node server/client/wallet that is designed from the ground up. I think it might have the ability to keep the full utxo set in ram. Still a work in progress… they’ve been working on it over 5 years maybe closer to 10.

https://github.com/libbitcoin

Reply to this note

Please Login to reply.

Discussion

Good points. Keeping utxo set in ram probably matters most to miners. And requiring 64 or 128 GB of ram in 10-20 years probably isn’t a huge ask (compared to data center costs).

I’ve spoken with Tadge IRL about utreexo at MIT earlier this year. As best I could understand, still waiting for a trustless way to initialize the accumulator. But way over my head