Masternode missed payment

oblox said:
Seems like a few people from here and BCT are having issues with the round robin style payouts. eduffield or UdjinM6 Any idea on why the reference nodes are skipping or is this not the case? Seems like there is an underlying problem if multiple parties are complaining of missing payments. I looked at one of my masternodes too and it had 4 days between payments a few days ago. Did something change in the latest 10.16.16 that caused the list to get fubared? Thoughts?
Click to expand...
Dsee/dseep message propagating and MN rank calculation algo will be changed in next release (already live on testnet).
//Would be nice if someone look into code to find some flaw there though.//
Anyway create bug report on JIRA please http://jira.darkcoin.qa/secure/Dashboard.jspa
This will help to keep track of it a lot.

PS. I know it doesn't feel good to miss payments:oops: but lets fix core (DS) issues first.:rolleyes:
 
Just to say. There is a payment in any block so one can find the delta between two of his payments and compare with the total number of mns. For example, I had last yesterday payment after 1197 blocks and let there was about 1300 masternodes at that period, so 100 missed their payments.
 
The distance of my last 20 Masternode payments in blocks. Without the number of Masternodes online at those blocks it's quite useless, but maybe some people will sleep better (or worse) when they see the variations:

1428 blocks
1257 blocks
1013 blocks
1015 blocks
1132 blocks
1041 blocks
2007 blocks
1315 blocks
1064 blocks
1929 blocks
1294 blocks
1023 blocks
1124 blocks
1013 blocks
1015 blocks
1083 blocks
1606 blocks
1981 blocks
1143 blocks
1525 blocks
 
Last edited by a moderator:
Also missed another going on 3. Went through 3500 blocks now. Im making a new wallet and changing the ip... do we need 120 confirms for new masternodes now? Or just 15?
 
oblox said:
15 to start it but I thought you needed the number of masternodes in terms of confirms to be on the list for payout.
Click to expand...

I don't know every line of the source code, but the only restrictions I've found is MASTERNODE_MIN_CONFIRMATIONS (15) and from that point you're in the payee list.

Once you're there your last payment mast be at least Number_of_Masternodes * 0.9 blocks ago.
 
crowning said:
I don't know every line of the source code, but the only restrictions I've found is MASTERNODE_MIN_CONFIRMATIONS (15) and from that point you're in the payee list.

Once you're there your last payment mast be at least Number_of_Masternodes * 0.9 blocks ago.
Click to expand...
That makes sense, pretty much in line with what I thought although wording it differently (since confirms would be blocks). I remember there was talk of a +/- 10% to the count so that makes sense.
 
I see ppl getting paid on 1st, 3rd and 4th...my last was on the 2nd and I see other ppl getting paid who got paid later than me on the 2nd. Something is really up...unless there is still some randomness and there will be outliers.
 
vertoe said:
this might be multiple masternode set up using start-many. This pays all masternode earnings to one address.
Click to expand...
Start-many doesn't pay to one address to my knowledge. The only way that happens is if you fund your 1k in the same tx using the add recipient button.
 
I thought start many wasn't really working / supported. After I moved my MN to a new wallet I got got first payment after about 1500 blocks.
 
UdjinM6 said:
Dsee/dseep message propagating and MN rank calculation algo will be changed in next release (already live on testnet).
//Would be nice if someone look into code to find some flaw there though.//
Click to expand...

The code looks (more or less, it's still a messy bit of global variables inherited from Bitcoin and therefore unnecessary hard to understand :rolleyes:) okay, but I think there's still a cleverly hidden bug somewhere.:

All my Masternodes are up to protocol version 70051
- smallest distance of payments: 184 blocks
- longest distance for payments: 2440 blocks

Right now there exist 1048 Masternodes.
 
crowning said:
The code looks (more or less, it's still a messy bit of global variables inherited from Bitcoin and therefore unnecessary hard to understand :rolleyes:) okay, but I think there's still a cleverly hidden bug somewhere.:

All my Masternodes are up to protocol version 70051
- smallest distance of payments: 184 blocks
- longest distance for payments: 2440 blocks

Right now there exist 1048 Masternodes.
Click to expand...

That's interesting... let's watch for this one more day, should "calm down" and become more even I guess...
 
While I had a look into the code anyway I think I found something that is not quite correct:

Code: 
void CMasternodePayments::CleanPaymentList()
{
  if(pindexBest == NULL) return;

  vector<CMasternodePaymentWinner>::iterator it;
  for(it=vWinning.begin();it<vWinning.end();it++){
    if(pindexBest->nHeight - (*it).nBlockHeight > 1000){
      if(fDebug) LogPrintf("CMasternodePayments::CleanPaymentList - Removing old masternode payment - block %d\n", (*it).nBlockHeight);
      vWinning.erase(it);
      break;
    }
  }
}

Me thinks

if(pindexBest->nHeight - (*it).nBlockHeight > 1000)

should be

if(pindexBest->nHeight - (*it).nBlockHeight > darkSendMasterNodes.size())
 
You must log in or register to reply here.
Back
Top