Unpopular opinion: recent bitcoin transaction spam that stuffs data in non-provably unspendable outputs will require bitcoin software to partition UTXO set in to probably spendable stuff stored in memory and probably not spendable stored on disk. In short, bitcoin can’t keep using RAM as a disk cache for entire UTXO set and eventually code will be forced to reflect real world constraints.
Discussion
Never underestimate the can do that can do anything to mess things up.
This is why good manners are better than safety protocols.
This is why a secretary who knows shorthand is better than AI note taking.
Without other humans we can't protect ourselves from other humans.
Fellowship is why religions that send the best and brightest into the mountain to do nothing are no better than security systems that unplug computers.
I wish there was an option to load the UTXO set into ram in its entirety upon start.
Very few people I know are talking about this.
I think it's an obvious solution to an issue that leads to centralisation if unresolved.
It's probably not glamorous or contraversial enough. Just get more RAM, you tight arses.
GM. Unpopular fact: The UTXO set isn't actually stored in RAM. It's stored in a database, the MOST ACTIVE PARTS of which is cached in memory. The other stuff just hangs around on mass storage. So the spam is mostly polluting your drive, plus it adds to initial block download time because its signatures have to be verified, plus some metadata, some of it will be in RAM, to manage the larger database size. But that's tiny.
So UTxO bloat is essentially not really an issue?
At least not in the way it is commonly portrayed. Increasing IBD time *is* bad (reduces the number of peers willing to start or re-start running a node). As is increased bandwidth use (especially in internet-third-world countries where data is metered / slow) and to some degree, so is increased database size. But it's certainly not like any node is going to overflow with out-of-memory errors because of spam.
Thanks for clarifying.
Exactly. Spamming UTXO set will cause more frequent dumping of RAM cache to disk which takes a long time…I don’t have a numerical estimate but you can estimate it yourself…try repeatedly halving the value of dbcache= in bitcoin.conf and time how long each run takes for initial block download…start at dbcache = 90% of your RAM…I’d bet you’d see a increase in sync time below a certain level and minimal improvement in sync time above a certain level of dbcache.
It's still Significantly worse than using an OP_Return, right?
Yes, because OP_RETURN outputs are provably unspendable and thus do not enter the UTXO dataset at all. After all, the U in UTXO stands for "unspent", and if something cannot be spent, then it doesn't need to be in an "unspent" pool.
It still increases disk and bandwidth requirements though. Your node can't simply "forget" the OP_RETURN data, as that data is still required to verify the block header hash, and to serve the blockchain to other nodes during IBD.
For bootstrapping a new node, teired storage allowing spammy transactions to stay on disk and not cached in RAM will fix the UTXO set bloat problem encountered during IBD.
Fact check: mostly false ❎
The performance bottle neck as applied to UTXO set occurs during IBD. Validating an incoming block immediately after rebooting your computer would happen before RAM cache of UTXO set would be made. But this has negligible effect on anything other than Initial Block Download.
Not sure what you're trying to say here, tbh.
That's (essentially) what the the BCash guys said in 2017, lol
Kinda, yeah. But moar ram isn’t the answer. Or at least it’s not the smartest answer.