So UTxO bloat is essentially not really an issue?
Discussion
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.