• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

payment queue

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.

I think this is worth highlighting - the voting is being done by the code deterministically, not under the influence of a masternode operator. Attempts to manipulate it would result in at least the invalid votes being rejected similar to invalid transactions or (depending on the situation) banning of that masternode by its peers.

If you want to look at the code, this would be a good place to start - https://github.com/dashpay/dash/blob/master/src/masternode-payments.cpp#L715
 
Thanks. I have been indeed working with @UdjinM6 for the whole day. He has been very helpful, and we exchanged messages, and he gave me several tips. We probably found what happened. But I also need to admit that the result had nothing to do with voting, but apparently there is a bias in favour of people with more technical abilities and people with multiple masternodes. I need to test this, and maybe Udjin wants to explain it himself. If not I will do it.
 
So basically on the wallet the "My Masternodes" tab kept telling me that I "Needed to restart" the MN. And the same on dashcentral.
And according to @UdjinM6 this should not be given much credit. I should instead used the other masternode to check if the first one is really on the list. And this can be done by writing:

dash-cli mastenrode list full <IP or txid>

in the other masternode. So people with more masternode (and tech savvy) will be able to triangulate their information and know if their other masternode went REALLY offline or offlist or not. And while others will either not restart a masternode that is offlist or keep restarting it a masternode that does not need to be restarted. Someone with multiple masternodes will use one to check the other.

So yes, I would say there is quite a strong bias that favours people with multiple masternodes. Just not through the voting procedure. In the meantime today I restarted my masternodes again, so I need to wait for 8 more days :'-( .
 
Will you publish the messages? Why you talk privately?
I have also reported Randomness in mn payee selection
And this was my last message in my investigation.

I am not sure how safe it is for me to release in public data about my masternodes. So I was grateful for the opportunity to write him in private. Also when I speak in private I can speak more freely. If I make an accusation, maybe a dumb one, no one gets offended. And I can be corrected more easily for everybody. At the end the result was that, according to my understanding, there is a bias. And so I reported on this. But no, you have no intrinsic right to know every person private communication. Just in case you were wondering :).
 
I am not sure how safe it is for me to release in public data about my masternodes. So I was grateful for the opportunity to write him in private. Also when I speak in private I can speak more freely. If I make an accusation, maybe a dumb one, no one gets offended. And I can be corrected more easily for everybody. At the end the result was that, according to my understanding, there is a bias. And so I reported on this. But no, you have no intrinsic right to know every person private communication. Just in case you were wondering :).

Nobody cares about your private relation with @UdjinM6 . :) :p:D But a lot of people care about the technical details on this issue. Thats what I am asking you to reveal. The technical details. You could censor the censible information in the conversation, and reveal us something technical we do not already know. Thats what I am asking, and my request is reasonable.

Oh yes, and if you dont want to offend or to be offended, use a nickname instead of your real name! Eponymous people like you, they are a plague for whatever online community, and they are the joy of the lawyers. I am sorry if this universal truth offends you. I have nothing personal against you, I am against online eponymity in general and I consider it as the root of many evil situations in the net.
 
Last edited:
So basically on the wallet the "My Masternodes" tab kept telling me that I "Needed to restart" the MN. And the same on dashcentral. And according to @UdjinM6 this should not be given much credit. I should instead used the other masternode to check if the first one is really on the list. And this can be done by writing:

dash-cli mastenrode list full <IP or txid>
in the other masternode. So people with more masternode (and tech savvy) will be able to triangulate their information and know if their other masternode went REALLY offline or offlist or not. And while others will either not restart a masternode that is offlist or keep restarting it a masternode that does not need to be restarted. Someone with multiple masternodes will use one to check the other.

So yes, I would say there is quite a strong bias that favours people with multiple masternodes. Just not through the voting procedure. In the meantime today I restarted my masternodes again, so I need to wait for 8 more days :'-( .

You dont need a masternode to triangulate the information.
You may use a simple empty wallet, put server=1 in dash.conf and then the command:

dash-cli masternodelist full <IP>

...should work.
 
Last edited:
Yup, demo is right - you don't need to be running a masternode to start up a full node on a VPS and check the status of your masternodes. You can even do it from any fully synced GUI Dash wallet - the software is the same. You can also use DashNinja, the mbmnq command for moobot or just ask someone you trust in PM or on discord to check for you.

When I first started a masternode I went through a similar learning curve, and it was sometimes down for several weeks before I figured out what went wrong. Consider it the cost of DIY instead of using one of the hosting services - in theory it should pay off in the long run!
 
Yes, restarted after "need restart" notice about week ago.
And that was our problem. Apparently when we restart the node goes back to the end of the queue. And we don't always need to do it. Don't ask me the logic, I have lost it few messages ago
 
After restart my MN still was in beginning of queue.
And normal time between payments is 7-8 days but 17 days already have accumulated...
And how do you know what is the position in the queue?
Because according to @UdjinM6 we cannot trust DashCentral. And there was no way he could tell me to find out what the actual position in the queue was.
 
After restart my MN still was in beginning of queue.
And normal time between payments is 7-8 days but 17 days already have accumulated...
When did u last hit start master node. Once you click that you go to the end of payment que. Your 7-8 days starts then I have gone 20 days before because of falling off the payment list.
 
Various methods exist to check the position, but I think it can only be approximated. DashCentral, dashman and the mbmnq command for moobot on slack all work for me, but availability of these tools depends very much on the choices you made while setting up your masternode.
 
Well, at the moment all my masternodes signal that they need to be restarted. And I shall just ignore it. When I had only 1 masternode I always ignored it because I was too terrorised to try it, and it worked very well. Then I tried to restart it one time to check if the position on dashcentral changed, and it did not change. Si I started restarting them every time they needed so thinking I was doing the right thing. And the result was no payment for 1 month :-(.
 
Back
Top