4

No. In any case, internet connection bandwidth and access is far more impactful to the network. Using a spinning disk, it's just you who will feel the pain during your initial full sync. Once you have got the blockchain on your spinning disk however, there is really no issue keeping it synced up, so long as you keep it running.


3

I have 131072 kB and don't get any locking issues here. It may be much more than needed. If you don't know what to do, I suggest trying twice what you have now, and see if that fixes the warning. If not, double again, etc. The more unswappable memory you have, the less leeway your OS has in choosing what to swap out when more memory is needed. If you do this ...


3

Yes. You will need to increase the log level in the daemon. E.g. set_log +daemon.rpc:DEBUG should suffice.


2

Some suggestions... Relying on those publicly known/advertised nodes is probably a bad idea to start with. Lots of people use those as remote nodes for their wallets for example, so I'd expect the operators make sensible use of the limit-rate-... options. Which brings me to the next point, what limit settings are you using? You should set these according ...


1

No, connecting to multiple remote nodes would increase your risk as you are then having to trust more remote nodes. Remote nodes are not a centralization risk in any case (you can use any remote node that is open and you can always use your own node). Using a remote node, your risk is hoping they are not a bad actor (e.g. they could be logging your usage/...


1

Running a node with only outgoing connections is less useful than running a node which allows incoming connections, but still useful. A node which cannot accept incoming connections will connect to nodes from its peer list, and as such is unlikely to find nodes which appeared recently on the network, since those addresses will propagate through the P2P ...


Only top voted, non community-wiki answers of a minimum length are eligible