payment queue

[nnx3]

devs take a time for own MN have look this have payment after 6 days https://www.dashninja.pl/mndetails.html?mnpubkey=Xe5UoX6fBcWuMKsgf3DPk29t5kWbKo853n few minuts ago
my mn waiitng 10 days for payment, DASH MN going to be scam

 

[bhkien]

devs take a time for own MN have look this have payment after 6 days https://www.dashninja.pl/mndetails.html?mnpubkey=Xe5UoX6fBcWuMKsgf3DPk29t5kWbKo853n few minuts ago
my mn waiitng 10 days for payment, DASH MN going to be scam

Payment depends on stability of your masternode and its connection.

 

[TroyDASH]

devs take a time for own MN have look this have payment after 6 days https://www.dashninja.pl/mndetails.html?mnpubkey=Xe5UoX6fBcWuMKsgf3DPk29t5kWbKo853n few minuts ago
my mn waiitng 10 days for payment, DASH MN going to be scam

https://dashpay.atlassian.net/wiki/spaces/DOC/pages/8880184/Payment+Logic

 

[nnx3]

Payment depends on stability of your masternode and its connection.

are U correct my VPS have 65% RAM used and 5-10% CPU usage, I have super fast datacenter in amsterdam.... 100% uptime.... please give me more TIPS for MN because my MN waiting 10,5 days and ) and queue decrease from 33 to 24 in 24Hours...!!!! In my opinion it is MANIPULATION by developer who have many more knownleadge than other users.

 

[GrandMasterDash]

are U correct my VPS have 65% RAM used and 5-10% CPU usage, I have super fast datacenter in amsterdam.... 100% uptime.... please give me more TIPS for MN because my MN waiting 10,5 days and ) and queue decrease from 33 to 24 in 24Hours...!!!! In my opinion it is MANIPULATION by developer who have many more knownleadge than other users.

It's open source, you can examine it and compile it yourself.

 

[nnx3]

It's open source, you can examine it and compile it yourself.

WHY some MN have a payment in 5 days and other in 10days?.... U have a proof on this link https://www.dashninja.pl/mndetails.html?mnpubkey=Xe5UoX6fBcWuMKsgf3DPk29t5kWbKo853n

open source.. hehe onyl few peoples have a time to study this scripts... please open eyes for the FACTS.!!

 

[qwizzie]

are U correct my VPS have 65% RAM used and 5-10% CPU usage, I have super fast datacenter in amsterdam.... 100% uptime.... please give me more TIPS for MN because my MN waiting 10,5 days and ) and queue decrease from 33 to 24 in 24Hours...!!!! In my opinion it is MANIPULATION by developer who have many more knownleadge than other users.

1 : check if your masternode is ENABLED by doing a grep on your IP address --> ./dash-cli masternode list full | grep -e IPADDRESS
2 : if your masternode is "ENABLED", then there are a few outcomes possible :

* MN payments is about 8 days, variance in MN payments can make that a few days longer or shorter.
* Masternode could skip receiving a MN payment if the masternode is very unlucky. This is a rare occassion and it happened to me a few times.
* Masternode could receive a double MN payment if the masternode is very lucky. This is a rare occassion and it happened to me a few times.

What does not help is talking about manipulation and scam
What does help is having some patience

 

[ericsammons]

WHY some MN have a payment in 5 days and other in 10days?.... U have a proof on this link https://www.dashninja.pl/mndetails.html?mnpubkey=Xe5UoX6fBcWuMKsgf3DPk29t5kWbKo853n

open source.. hehe onyl few peoples have a time to study this scripts... please open eyes for the FACTS.!!

Try to understand how it works before attacking it.

Here is a simple description:

If there are 4,500 Masternodes, then you begin at position #4500. Every time a MN gets paid, you move up one: to 4499...4498...etc.

However, once you get in the top 10% of the queue (in this case #450) you become eligible to get paid. Every MN that is eligible can be randomly selected, and in this example, they each have a 1 in 450 chance of getting selected for each block.

So you could get paid on the very first block after you get to #450. Or, you could get paid after 10 blocks, or 20, or 300. You could even get paid after more than 450 blocks, because each block means you have a 1 in 450 chance of getting selected, and you could just be unlucky. There is no guarantee that you'll get paid within 450 blocks.

All this means you could get paid very quickly (under 7 days), or it could take a long time (over 12 days). Experienced MN owners, however, will tell you that it averages out in the end.

 

[UdjinM6]

You are making assumptions that cannot be proved by any existing code.

How payments actually work:
- every node is aware when some specific masternode was funded (thanks to blockchain)
- every new masternode has to wait at least 1 full cycle (n blocks equal to number of masternodes) before it gets its first payment
- active masternodes are ranked in 2 steps:
1. ordering by last payment for everyone
2. calculating deterministic rank based on mn collateral and blockhash for top 10% of masternodes from the step 1
Top masternode from step 2 is voted by other top10 masterndoes picked with a similar algo and is declared a "winner" which must be paid by miners (if it has more than 6 votes).

You can verify all of this in the code. No one (inc devs) have any influence or special privileges for their masternodes in that process.

PS. moving this to a separate thread as it has nothing to do with 12.2 release

 

[nnx3]

Try to understand how it works before attacking it.

All this means you could get paid very quickly (under 7 days), or it could take a long time (over 12 days). Experienced MN owners, however, will tell you that it averages out in the end.

have look few last week MN was between 4500-4700. Easy calculation give U info 4600 - 10% = 4140MN block every 3minutes = 480 block per day
4140/480 = 8.625 THat mens any MN should not have the payment faster than 8,6 DAYS

I give U link with MN who have a payment with 5-6 days. and easy calculation WHO give info about bugs!!!!

 

[nnx3]

Top masternode from step 2 is voted by other top10 masterndoes picked with a similar algo and is declared a "winner" which must be paid by miners (if it has more than 6 votes).

You can verify all of this in the code.

it means that If U are owners of many MN U can easy block other masternode (like me MN) by voting for your own, hehe its not fair play

 

[UdjinM6]

it means that If U are owners of many MN U can easy block other masternode (like me MN) by voting for your own, hehe its not fair play

Define "many" and calculate chances to do so.

 

[bhkien]

are U correct my VPS have 65% RAM used and 5-10% CPU usage, I have super fast datacenter in amsterdam.... 100% uptime.... please give me more TIPS for MN because my MN waiting 10,5 days and ) and queue decrease from 33 to 24 in 24Hours...!!!! In my opinion it is MANIPULATION by developer who have many more knownleadge than other users.

I you think so, you have better sell all your Dash now, its current price can make you profit a lot.

 

[IcyBud]

I give U link with MN who have a payment with 5-6 days.

ok, please post this info!

You should also mention that MN drop of the payment list all the time - that also changes the payment time!

 

[Sven]

Easy calculation give U info 4600 - 10% = 4140MN block every 3minutes = 480 block per day
4140/480 = 8.625 THat mens any MN should not have the payment faster than 8,6 DAYS

Dash block time is 2.5 min, not 3 minutes. So your own calculation drops to 7.2 days with 576 blocks per day. On top of that, some of the 4140 bottom nodes will crash, get restarted or shut down completely and drop out before they reach the top 10%, making the others rise to the top even faster.

 

[Pietro Speroni]

Here are two masternodes which I own which haven't been paid one in 24 days and one in 1 month.
Basically they never were paid from when we moved to the new version of the code.
I raised the server supporting them to be 2048 MB. When I did this it was already a couple of weeks that they should have been paid.

According to dashcentral they are ready to be paid from a long time ago. And still the last one is in position 220 in the queue. Which means there are 219 nodes that have not been paid from even longer.

After about 8 days from when I raised the server all my masternode went offline and I had to restart them. I don't know what happened. I suspect it is possible to push a masternode out by DDOS attacking it. I remember it was theorised in some videos criticising dash but the answer was that this never happened. But maybe now with the new valuation of DASH it's starting to be worth doing it.

In any case, as it is right now it is not working. It is not working for me, and it is not working for the owners of the 219 masternodes above.

Also I notice that I took some unpopular positions in my voting decisions (*). And this could be used as a way to push people out of the masternode business (you cut their funding, they move away and they don't vote anymore)
As such if it is an attack it could be:

1. an attack from outside (showing masternode are not a viable business, thus making people sell, and lowering the value of Dash);
2. an attack from the inside for economic reasons (another masternode owner using this to move their masternode faster in the queue by pushing the other masternode above him out);
3. an attack from the inside for political reasons.

(*) you can search for my posts in this forum if you want to know what I refer to. One even got 11 disagreement! I think it must be a record.

 

[Pietro Speroni]

2. calculating deterministic rank based on mn collateral and blockhash for top 10% of masternodes from the step 1
Top masternode from step 2 is voted by other top10 masterndoes picked with a similar algo and is declared a "winner" which must be paid by miners (if it has more than 6 votes).

WHAT?? So it is not random how the masternodes are paid, but they are voted? This is a terrible idea

 

[Pietro Speroni]

Define "many" and calculate chances to do so.

Sorry, it is not his or her job to calculate this. It is your job as member of the core group to prove that it is fair.
Beside every extra masternode that a person own or that a group of friends own will support each other raising the probability to be paid. In other words this is a system to create groups of people that support each other in spite of the rest of the community, thus creating fractures in the community. Cutting away people from the community. And making the price of Dash drop. Did I mention it's a terrible idea?

 

[UdjinM6]

...
Here are two masternodes which I own which haven't been paid one in 24 days and one in 1 month.
Basically they never were paid from when we moved to the new version of the code.
I raised the server supporting them to be 2048 MB. When I did this it was already a couple of weeks that they should have been paid.

According to dashcentral they are ready to be paid from a long time ago. And still the last one is in position 220 in the queue. Which means there are 219 nodes that have not been paid from even longer.

After about 8 days from when I raised the server all my masternode went offline and I had to restart them. I don't know what happened. I suspect it is possible to push a masternode out by DDOS attacking it. I remember it was theorised in some videos criticising dash but the answer was that this never happened. But maybe now with the new valuation of DASH it's starting to be worth doing it.

In any case, as it is right now it is not working. It is not working for me, and it is not working for the owners of the 219 masternodes above.

Also I notice that I took some unpopular positions in my voting decisions (*). And this could be used as a way to push people out of the masternode business (you cut their funding, they move away and they don't vote anymore)
As such if it is an attack it could be:

1. an attack from outside (showing masternode are not a viable business, thus making people sell, and lowering the value of Dash);
2. an attack from the inside for economic reasons (another masternode owner using this to move their masternode faster in the queue by pushing the other masternode above him out);
3. an attack from the inside for political reasons.

(*) you can search for my posts in this forum if you want to know what I refer to. One even got 11 disagreement! I think it must be a record.

I have no idea what happened to your masternodes either and I won't have any without some additional info like mn txid or maybe better a debug.log from one of your remote nodes. I highly doubt that your forum ranks are linked to your MN failures, I'd guess it's a coincidence but let's see what caused failures first before jumping the gun with conspiracy theories. You can PM me here on forum or send debug.log to [email protected] if you need help.

Sorry, it is not his or her job to calculate this. It is your job as member of the core group to prove that it is fair.
...

I disagree. She or he started with accusations that developers are affecting voting somehow. The code is open source and available for everyone, I also outlined the algo in plain English as simple as I can. The voting results are also there right in the network. Now it's her or his turn to prove me that it's not working as I described or GTFO. I'm a bit tired of trolls jumping around with their empty accusations, I have a work to do you know.

...
Beside every extra masternode that a person own or that a group of friends own will support each other raising the probability to be paid. In other words this is a system to create groups of people that support each other in spite of the rest of the community, thus creating fractures in the community. Cutting away people from the community. And making the price of Dash drop. Did I mention it's a terrible idea?

So, let's sum it up. Large Dash holders (masternode owners) will form groups to push the value of their investment (price of Dash) down, correct?

 

[Pietro Speroni]

I have no idea what happened to your masternodes either and I won't have any without some additional info like mn txid or maybe better a debug.log from one of your remote nodes. I highly doubt that your forum ranks are linked to your MN failures, I'd guess it's a coincidence but let's see what caused failures first before jumping the gun with conspiracy theories. You can PM me here on forum or send debug.log to [email protected] if you need help.

Hi UdjinM6, sure let's investigate this. I am sending you a message here.

I disagree. She or he started with accusations that developers are affecting voting somehow. The code is open source and available for everyone, I also outlined the algo in plain English as simple as I can. The voting results are also there right in the network. Now it's her or his turn to prove me that it's not working as I described or GTFO. I'm a bit tired of trolls jumping around with their empty accusations, I have a work to do you know.

I don't know who this person is, but I don't think it's a troll. Sounds more like someone who made a big investment in DASH to buy a masternode and it's now frustrated that it's not paying back as it was explained. And my experience supports him.

It would be useful if there was a list of masternodes, with the average number of days in which have been paid and the last time they have been paid.

If you go to
https://www.dashninja.pl/
You can see there are many masternodes that haven't been paid in 2-4 weeks.

it's not ok.

Respect to who should prove it:
One thing is proving that is not working as you claim, another is proving that the algorithm you explained is fair.

Now if the behaviour was fully random, then it would be her job to prove it is not. But because I learn there is an element of voting involved (and voting is not always fair, it depends on the form of voting), it is the job of the core team (of which you are part, I gather) to show that this kind of voting is fair to all participants in this context. So I would say this is part of your work (or of someone's work in the core team)

So, let's sum it up. Large Dash holders (masternode owners) will form groups to push the value of their investment (price of Dash) down, correct?

It wouldn't be the first time that someone tries to have a personal short term gain at the expense of the collectivity long term behaviour. The bitcoin community has been ripe for this behaviour.

 

[strophy]

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...

 

[thephez]

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

 

[Pietro Speroni]

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.

 

[Pietro Speroni]

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 :'-( .

 

[demo]

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.

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.

 

[Pietro Speroni]

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 .

 

[demo]

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 . 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.

 

[demo]

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.

 

[strophy]

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!

 

[Asatur]

Same problem few last weeks: http://dl3.joxi.net/drive/2017/12/05/0018/1430/1230230/30/0601eb4b73.png
Masternode is online, enabled etc.