no, memory is not just used for 1MB blocks. it's also used to store the mempools plus the UTXO set. large block attacks
Again, you're wrong on the technology. The UTXO set is not held in ram. (There is caching, but its arbritary in size, controlled by the dbcache argument).
have the potential to collapse a full node by overloading the memory. at least, that's what they've been arguing.
"They" in that case is sketchy nutballs advocating these "stress tests", and _you_ arguing that unconfirmed transactions are the real danger.
Super weird that you're arguing that the Bitcoin network is overloaded with average of space usage in blocks, while you're calling your system "under utilized" when you're using a similar proportion of your disk and enough of your ram to push you deeply into swap.
...
Thanks for this tid-bit about the UTXO database. This is the kind of info that someone who is mildly familiar with database technology but doesn't really want to make a lifes' work of studying the technicals find cumbersome to pick out. Especially since modern Bitcoin is already past what is realistic to run behind my ($80/mo) connectivity so unless/until I set up a VM somewhere it's kind of a textbook exercise.
Just from knowing a little about database tuning and ram vs. disk-backed memory, I have always wondered if people have make projections about performance of the validation process under different scenarios and whether they can/will become problematic. One think I've always wondered if it would be possible to structure transactions such that they would load validation processes to heavily on queue, and particularly if it is common case to push more and more data out of the dbcache. Any thoughts on this that can be quickly conveyed?