Prevent mining when disconnected from network
Opened this issue · 6 comments
I noticed that blurd will continue to mine after a suspend + resume when no internet access exists on resume. It will mine and use CPU resources indefinitely, not realizing it has no valid peers and no internet connection. Not even a valid interface, since there was no valid wifi connection nor ethernet connection.
It seems that blurd could have heuristics to detect this edge case and stop mining, until it is reconnected to the network. Some heuristics might be OS-level detection of a working network interface that is not loopback, maybe via some kind of ping. A harder edge case is to detect when we have a valid internet connection but no packets (for whatever reason, such as firewall or misconfiguration) are getting through.
Part of the issue seems related to the fact that in XMR world, it's valid for a single node to mine, while in BTC world, it's always required to have 2 nodes connected to enable mining.
One idea is "If blur has not seen a block or message from a valid network peer in X minutes, have a 50% chance of stopping mining." This allows some nodes to stay online in case there is some actual bug in the difficulty adjustment algorithm or catastrophic network event. The main problem in fixing this issue seems to be how to correctly detect it, and not get false positives which would have a detrimental effect on the P2P health of the network.
Thank you for opening this issue, and for the detail you included. Specifically, the BTC-world behaviors were ones that I was hoping you would note. Since we can't sync to the network unless there are at least 2 peer connections (3 peers total in network, including our own node) in XMR as well... this seems like something that is a design mistake or flaw (whether unintentional or otherwise).
I will be looking into this further ASAP.
It is not valid for a single node to mine. Rebase to monero and this problem will be resolved.
Right, where ignoring problems and disparaging those who ask questions is considering "solving" a "problem".
This issue isn't solved on Monero. There's just so few full nodes that the network is blissfully unaware of the problems with consensus. Recall how pools go off on their own forks occasionally? That's the issue being voiced here.
So are you here to help? If not I'll presume you're here to harm
no. mining stops if you lose connections. that is the stated issue here
no. mining stops if you lose connections. that is the stated issue here
If a node on monero thinks it is fully synced, you will be able to mine. That is the problem here and it has nothing to do with connections (which, it should). Core receives a callback from m_p2p.get_payload_object().is_synchronized(). If that evaluates to true, anyone can start mining, or continue mining, on any Cryptonote network.
@HorribleGelatinousBlob I am new to XMR internals, so I might be mis-understanding. But it seems that you are saying this bug is specific to BLUR and merging in new XMR changes would fix it. Is that correct? Did a bug like this previously exist in XMR and was fixed? Or are you saying BLUR introduced this?