People are working on it but I don't actually see the issue. Storage is the cheapest thing to upgrade on a computer.

I think that problem is just a feature of how the Bitcoin Core/Knots software handles chain state. Libbitcoin is working on a better solution (imo) that puts the focus where it belongs RAM and CPU optimization. People aren't going to not be able to afford the RAM and CPU that would be needed to index everything. I have said before that "UTXOs" are just one implementation's way of telling you what the chainstate is and not necessarily needed to keep a verifiable index of coins.

Reply to this note

Please Login to reply.

Discussion

What are the other options? Other than UTXOs? I wouldn't have guessed that could be done... What about when 11 billion people are using it? Are we talking full closets dedicated to ram?

UTXOs are like a coin you can split and join. The other option is accounts, fuck that.

The database doesn't have to index everything. It should index in reverse and not store anything spent, and the older, the less optimized, as it's unlikely to ever be spent the further you go back.

Yes, but I think he was only talking about nodes. I don't think utxos can be gotten rid of, but maybe there's another option than holding the utxo set in ram. Idk, maybe he'll clarify

That partial index sounds good. Are there any other options?

It's tough to wrap the mind around but memory maps are very fast to query and don't have to have a list of UTXOs. On a per block basis, "is the coin being double spent?" and "is the coin there(in the spending address)?" solves the issue of needing to know where all the coins are simultaneously.

Thanks, I'm reading about it. Seems like it should already be using mmap... But I should read more...

Core does not, Libbitcoin does.

Just have the chainstate be queriable. Here, Eric Voskuil jumps in the thread to explain it pretty well the the Bitcoin Core Devs: https://delvingbitcoin.org/t/libbitcoin-for-core-people/1222/27