Hi Chris,

First, a minor quibble: Bitcoin Core doesn’t have zero overhead for storing a transaction. They’re stored as CTransaction objects in hashmaps and things, so the actual memory used when you take C++ heap overhead and fragmentation into account is higher. Also just doing a quick eyeball divide using the blockchain.info charts suggests the average size is more like 500 bytes currently, not 250.

With current mempool sizes, my node is using 1.5 gigs of virtual memory and has an RSS of 440mb. As the mempool would be churning quite a lot as new transactions come in and old ones get confirmed, I’d imagine most of it sits in RSS not paged out to disk. Quite a few nodes run on cheap virtual private servers (as indeed this one does). So I doubt they have hundreds of megs of actual RAM free. My VPS has none free at all. It’s only viable due to unneeded stuff being paged to disk.

So once we run out of capacity mempools would start bloating up. You’re right that this wouldn’t cause problems the very same day or anything. Node crashes and stalls (as they start heavily swapping and get really slow) would happen sporadically across the network as each one hits its own memory limits, which are unknowable.

You’re right that node crashes are a worst case scenario. However it makes little difference — the end result whether one believes your take or mine is the same, with the network eventually recovering after users leave, taking their wealth and political support with them. There would be no sustained high demand situation as some people seem to think, and there would be a lot of serious problems for users until load shedding was complete.