Interesting discussion here, but extraordinary claims require extraordinary proof. Open source projects in general, and determinstically built cryptocurrency projects in particular, should be immune to this sort of attack on the developer's reputation because it is literally possible to verify that the binary you are running was built from the code you see on github. I have done this and confirmed it myself, and you are welcome to follow my documented procedure here. So now we must demonstrate that selective voting exists on the blockchain. I am sure one of the devs here can point us at the appropriate code to put that issue to rest.
At a higher level, I think the issue here is a misunderstanding of the term "voting". This is not contentious voting in the sense of voting a budget proposal up or down, but rather voting to establish consensus. The same kind of voting takes place for InstantSend transactions. It exists to eliminate reduce the chances of a hypothetical bad element (as you have suggested exists) from voting for their own benefit, because to be able to reliably influence the vote, they would need to control both the source code and a supermajority of masternodes. Both of these conditions can be demonstrated not to be true, the first by the process I described above, and the second by the gradual growth in masternode count over time.
You can actually view the results of the voting from the command line using "dash-cli masternode winners" and see that the winners of the next 10 blocks into the future have already been calculated and locked in. The vote simply ensures that everyone agrees who should be paid next, and that everyone is following the same deterministic selection algorithm.
That leaves us with your two misbehaving nodes, which are presumably included in the several pages of masternodes in the list you referenced. I copied the list of nodes which have not been paid in over 1 week 6 days and found a total of 242 masternodes "late" receiving payment. Of that 242, 105 (43%) show status inactive, mostly due to old protocol or version. A further 46 (19%) show active, but are in fact running an old protocol or version. Another 6 show unknown version. That leaves only 85 (35%) that are apparently running the right version, but are missing payment for no obvious reason. This number probably includes your two. Out of a total of 4626, I am inclined to believe that this 85 have some other form of user error or even display error (remember DashNinja has had serious database issues recently) rather than malicious intent.
Now that we are close to proof of no malicious intent, let's stop the accusations and get back to working on what is wrong with your configuration. Why do they show disabled in your screenshot? Can you find someone like UdjinM6 or myself on Discord or PM and we can continue trying to track down what went wrong, where and why...
At a higher level, I think the issue here is a misunderstanding of the term "voting". This is not contentious voting in the sense of voting a budget proposal up or down, but rather voting to establish consensus. The same kind of voting takes place for InstantSend transactions. It exists to eliminate reduce the chances of a hypothetical bad element (as you have suggested exists) from voting for their own benefit, because to be able to reliably influence the vote, they would need to control both the source code and a supermajority of masternodes. Both of these conditions can be demonstrated not to be true, the first by the process I described above, and the second by the gradual growth in masternode count over time.
You can actually view the results of the voting from the command line using "dash-cli masternode winners" and see that the winners of the next 10 blocks into the future have already been calculated and locked in. The vote simply ensures that everyone agrees who should be paid next, and that everyone is following the same deterministic selection algorithm.
That leaves us with your two misbehaving nodes, which are presumably included in the several pages of masternodes in the list you referenced. I copied the list of nodes which have not been paid in over 1 week 6 days and found a total of 242 masternodes "late" receiving payment. Of that 242, 105 (43%) show status inactive, mostly due to old protocol or version. A further 46 (19%) show active, but are in fact running an old protocol or version. Another 6 show unknown version. That leaves only 85 (35%) that are apparently running the right version, but are missing payment for no obvious reason. This number probably includes your two. Out of a total of 4626, I am inclined to believe that this 85 have some other form of user error or even display error (remember DashNinja has had serious database issues recently) rather than malicious intent.
Now that we are close to proof of no malicious intent, let's stop the accusations and get back to working on what is wrong with your configuration. Why do they show disabled in your screenshot? Can you find someone like UdjinM6 or myself on Discord or PM and we can continue trying to track down what went wrong, where and why...
.