pull down to refresh

RAM is a bigger bottleneck than storage for node runners
I had no notable issues with a dbcache of 4GB on an Odroid M2 I sync'd and ran earlier this year, even though it didn't have the whole utxo db cached. It does have NVME and good controllers though - so that may help not having issues with loading from disk. Oh and I'm supposed to get that RPi 8GB delivered this Saturday, so I'll have a go at setting it up and doing IBD with it - so I'll keep you posted on that. Either way, if it works on the Odroid, it should work on the Pi, so it'd be at best a coding issue.
I don't have much to say about how filtering at the relay level disadvantages small miners
Back of the envelope math, anyone do correct me if I mess up somewhere:
If you have 8 slots where you randomly connect to peers and 20% of the network filters txs, then you have... .00025% chance to have every slot filtered, and thus 99.99975% chance of having at least 1 non-filtering peer. So in theory it sounds fine. But how many of these peers are actually capable of delivering all txs to you? 10% of the non-filtering part of the network? Let's do the math again:
8 slots, 8% desirable peers, gives you a 49% chance (instead of 57% if no one were filtering) of having at least 1 desirable peer.
This implies that it's not an immediate problem, especially since your node will disconnect malfunctioning or slow outgoing peers, so you have infinite tries and most nodes will eventually find a good set of peers (that won't work for filtering peers right now though); this is one of the things that has been engineered pretty awesomely over the years. But ultimately, when the % of the network that is filtering grows, this could become a problem: it is a forward-looking concern.
Cool, looking forward to your test results on IBD.
reply