Hey guys, I was chatting in the token channel (Discord) yesterday and had a ping from both our mods - @Mightyfool and @neo, regarding concerns re: bad actors exploiting the emissions system. While these conversations tend to happen amongst specific groups and threads in discord, as well as the community forum, I thought as it affects everyone supporting the project, that a broader post about it, was a good idea. First of all, I would like to take the opportunity to say this is now live product, or rather network, development (a good thing!) - what is being uncovered/seen/tried is a result of that - and means we will all be able to benefit, sooner rather than later, from a strong, stable and scaling network, as a result of the issues being identified and the actions being taken. Network emissions, as some will know, are currently suppressed from intended levels. At some point in the near future, they will increase in order to realign with the emissions schedule that is outlined in the white paper (so they can perform their intended role, which is to support capacity growth and consistent earnings, as more data starts to flow into the network/onto the nodes). Speaking of nodes - there a couple of items I think important to address.
-
There is no benefit to emission earnings by turning nodes off and on. While it may create network instability if a significant number of hosting nodes do this (replication of data is a key defense mechanism here) - based on our investigations, the node operators engaging in this behavior receive no increase in emissions as a result of it.,
-
Related to the emissions payout themselves, there have been reports of unequal earnings, based on node proximity (thanks to latency). This was addressed through a recent update, whereby initial response time is no longer a factor in payment selection. All responses are now waited upon, prior to nodes being selected for payments.,
Building on the above, and related to the current emissions exploit ⌠we speak a lot internally about the need for specificity and simplicity - as a result we talk in binary about âgood nodesâ and âbad nodesâ. If a node can be reached, itâs a good node. If a node cannot be reached, itâs a bad node. A good node should be eligible to receive emissions, a bad one, should be shunned/removed from the network (routing table). A node, if it is not actually hosting the data it claims to be, is a bad node. A good node, will be able to prove it holds the data that it is/was rewarded for. We are aware that some node operators have been deleting data from their nodes and are therefore claiming rewards for a service they are not providing. There is much we could say here, but I guess in the spirit of live network development, we should instead just thank you for your âŚ. ingenuity and in drawing our attention to this vulnerability. We have now prioritized a remedy for this exploitive and potentially damaging behavior, and will be rolling the same out asap. Itâs worth noting here again, the importance of data replication in countering the behavior of bad nodes. While it pains me a little that this post is not all that positive - although improvement should always be regarded with a little of that for sure - it does mean that we can save the exciting updates on pre-Christmas roadmap items such as paymaster (working in Dave) and app building (big news there too) for the weekly Thursday update. Going forwards we will be adding a little more emphasis to the blog and will try and gather/integrate the open issues and commentaries, where possible, into it. Following Thursdayâs regular post, there will also be a number of the MaidSafe team in Discord to answer questions and chat around any specifics so that folks feel more connected and in sync (similar to how we did with the last couple of spaces).
Onwards we go!!
@Bux