v0.10.16 - Onyx v2

AjM said:
Sync problems with v101611 anybody?
Seems ok for now.
Click to expand...
My qt wallet stuck today at "1 hour behind". Closed, opened it again and it synced.
I guess Evan will start to squash some old bugs once he is satisfied how new Darksend implementation works :)

EDIT: I didn't remove peers.dat.... will do this now
 
UdjinM6 said:
I guess Evan will start to squash some old bugs once he is satisfied how new Darksend implementation works :)

EDIT: I didn't remove peers.dat.... will do this now
Click to expand...
Cool, is this rumor or fact?
 
flare said:
Checked this against ALL my customers nodes, i don't get a single entry in any debug.log ...
Click to expand...

Me neither.

But what's REALLY odd:
flare said:
Code: 
ubuntu@ip-10-0-2-201:~$ cat .darkcoin/debug.log | grep "CActiveMasternode" | tail -n 20
Click to expand...

I don't get ONE single CActiveMasternode::RegisterAsMasterNode() entry in the logs of 3 of my Masternodes.
Nothing. Not a single one.
And there should plenty of them, because these Masternodes are listed as active.

I'm using the official Linux 64 bit binaries.

I think I'll build them myself from GIT like you did, maybe there's a difference...
 
UdjinM6 said:
My qt wallet stuck today at "1 hour behind". Closed, opened it again and it synced.
I guess Evan will start to squash some old bugs once he is satisfied how new Darksend implementation works :)

EDIT: I didn't remove peers.dat.... will do this now
Click to expand...

Are there other instructions to follow when updating to 16.11?
Do I remove peers.dat on both local and server?
 
djcrypto said:
Are there other instructions to follow when updating to 16.11?
Do I remove peers.dat on both local and server?
Click to expand...
There is no really need for that I believe, it should just help to avoid "old" clients so wallet will not try to connect to them, fail :) and remove them from the list one by one.
But in a matter of testing and looking in debug.log to find something unusal this might help. But I see nothing unusual so far....
 
djcrypto said:
Are there other instructions to follow when updating to 16.11?
Do I remove peers.dat on both local and server?
Click to expand...
You can do that, no harm, just in case, i always delete peers.dat from both local and remote when updating.
 
crowning said:
I think I'll build them myself from GIT like you did, maybe there's a difference...
Click to expand...

Even with the self-build binaries there's no difference.

I think I'll add some lines of additional Log, build again and see what's going on...
 
Oh, so this is where ya'all are talking ;)

Has Evan uploaded 10.16.12 yet? He said he fixed mixing issues on BTC this morning...
 
crowning said:
flare said:
Checked this against ALL my customers nodes, i don't get a single entry in any debug.log ...
Click to expand...
I think I'll add some lines of additional Log, build again and see what's going on...
Click to expand...

Okay, adding a ton of my own debug info tracked this one down, and even when I'm a bit ashamed to admit it's user error the implications of my findings are too interesting to not share them here:

  1. I have a hot/cold setup for my Masternodes.
  2. I have a script which updates my remote Masternodes automatically. The binary, a generated darkcoin.conf and a couple of other things. Somehow :smile: about one month ago the configuration entry "masternode=1 got lost, so from that day on all of my hot Masternodes did NOT have that line in darkcoin.conf. :facepalm: (the cold ones have, though)
  3. This means CActiveMasternode::RegisterAsMasterNode() is never successdully executed:
    1. Private key is not checked
    2. External IP and port is not checked
    3. Wallet lock is not checked
    4. vin is not checked
    5. Masternode is not relayed to the peers
    6. A ton of other things...
  4. Most of the above is not really THAT important for a hot Masternode to run properly , but I still fail to see why my Masternodes were seen (and paid of course) by the rest of the network at all.
 
 
Anyone not using superputty or some other multi-instance update to update multiple nodes is wasting precious time. Makes it incredibly easy to update.
 
denom working :) well done evan.

*Edit* have been hit with two 0.1 fees

*edit2* 3 fees and only 1 round complete

Will turn off and wait a few days

*Edit 3* I see success reported on bct and others are successful.
So guess I've just been really unlucky. 3 fees/2rounds
 
Last edited by a moderator:
crowning said:
Okay, adding a ton of my own debug info tracked this one down, and even when I'm a bit ashamed to admit it's user error the implications of my findings are too interesting to not share them here:

  1. I have a hot/cold setup for my Masternodes.
  2. I have a script which updates my remote Masternodes automatically. The binary, a generated darkcoin.conf and a couple of other things. Somehow :smile: about one month ago the configuration entry "masternode=1 got lost, so from that day on all of my hot Masternodes did NOT have that line in darkcoin.conf. :facepalm: (the cold ones have, though)
  3. This means CActiveMasternode::RegisterAsMasterNode() is never successdully executed:
    1. Private key is not checked
    2. External IP and port is not checked
    3. Wallet lock is not checked
    4. vin is not checked
    5. Masternode is not relayed to the peers
    6. A ton of other things...
  4. Most of the above is not really THAT important for a hot Masternode to run properly , but I still fail to see why my Masternodes were seen (and paid of course) by the rest of the network at all.
Click to expand...
There are some checks of vin in ProcessMessageMasternode (on receiver side) and in ThreadCheckDarkSendPool actually so it should be ok.

When there is no masternode=1 on remote node it will check keys and vin https://github.com/darkcoin/darkcoin/blob/master/src/masternode.cpp#L129
update lastTimeSeen and add itself into MN list https://github.com/darkcoin/darkcoin/blob/master/src/masternode.cpp#L141-L142
and only then it will fail https://github.com/darkcoin/darkcoin/blob/master/src/activemasternode.cpp#L296
but still relay itself to others https://github.com/darkcoin/darkcoin/blob/master/src/masternode.cpp#L149
So you'll get your 70 minutes and then your node will become inactive.
Definitely should fail faster :)

EDIT: http://jira.darkcoin.qa/browse/DRK-125
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top