MN - Coins on Trezor - Cannot launch MN - 5 days downtime

[BitCrusher]

Hello,

I setup two masternodes about a month ago using the guides provided by TAO, with collateral stored off a Trezor wallet. All went smooth. As of the recent updates, there have been some issues with restarting the MN's. I have tried to reinstall from scratch and even resent the 1,000 DASH deposits to new addresses now for a total of 3x, just in case I had accidentally triggered a ban (which I wouldn't even know how to check).

Can anyone please confirm if they are able to run the 12.2.1 along with the 70208 protocol, with collateral off of a Trezor hardware wallet? Is there a chance the Trezor hardware needs to be updated?
I've updated the Dash Masternode Tool, updated dashman, dashd, and sentinel all to newest versions. I've resetup multiple servers, doing the whole process from scratch over again, but to no avail.

Can anyone please point me in the right direction? Costing quite a bit with downtime here.
Any help is much appreciated.

Thanks.

 

[UdjinM6]

Can you clarify what are the issues exactly? What's the status of your MNs? Are they switching to NEW_START_REQUIRED all the time or ..?

 

[BitCrusher]

Can you clarify what are the issues exactly? What's the status of your MNs? Are they switching to NEW_START_REQUIRED all the time or ..?

Thanks for the follow-up.

One of them yesterday I was able get the status to PRE_ENABLED but after that the status just went blank, and it never fully enabled. Typically see a WATCHDOG_EXPIRED or NEW_START_REQUIRED from the Dash Masternode Tool.

The first time I set these up and installed them, everything went through without any issues.

Would it be worth it to use the native dash wallet for setting these up? Or can someone confirm that there's no current issues with the Trezor wallet? Previously we were running 12.1 dashd I believe, no problems. I think we were having some memory limitations on the server and the masternodes had shut down at one point. I've reinstalled/resetup multiple different servers with new IP's and moved funds to different collateral addresses, just in case they had hit some sort of ban list inadvertently (Perhaps the low-ram issues were causing these to previously malfunction on the network). I'm a bit puzzled at this point.

Please let me know if I should provide more information.. thanks!

dashman version 0.1.25 (37-g38fb02f) - Tue Nov 14 17:25:19 UTC 2017
gathering info, please wait... DONE!

hostname : vultr.guest
host uptime/load average : 0 days, 0.55 0.62 0.63
dashd bind ip address : (removed)
dashd version : 0.12.2.1
dashd up-to-date : YES
dashd running : YES
dashd uptime : 0 days, 15 hours, 54 mins, 12 secs
dashd responding (rpc) : YES
dashd listening (ip) : YES
dashd connecting (peers) : YES
dashd port open : YES
dashd connection count : 51
dashd blocks synced : YES
last block (local dashd) : 770693
(chainz) : 770693
(dash.org) : 770693
(dashwhale) : 770691
(masternode.me) : 770692 - no forks detected
dashd current difficulty : 54554185.16695707
masternode started : NO
masternode visible (local) : NO
masternode visible (ninja) : YES
masternode address : (removed)
masternode funding txn : (removed)
masternode queue/count : 0/0
masternode mnsync state : MASTERNODE_SYNC_FINISHED
masternode network state :
masternode last payment : never
masternode balance : 0
sentinel installed : YES
sentinel tests passed : YES
sentinel crontab enabled : YES
sentinel online : NO
Exiting.

~/.dashcore$ ./dash-cli mnsync status
{
"AssetID": 999,
"AssetName": "MASTERNODE_SYNC_FINISHED",
"AssetStartTime": 1510624563,
"Attempt": 0,
"IsBlockchainSynced": true,
"IsMasternodeListSynced": true,
"IsWinnersListSynced": true,
"IsSynced": true,
"IsFailed": false
}

~/.dashcore$ ./dash-cli masternode debug
Not capable masternode: Masternode not in masternode list

~/.dashcore$ ./dash-cli getinfo
{
"version": 120201,
"protocolversion": 70208,
"walletversion": 61000,
"balance": 0.00000000,
"privatesend_balance": 0.00000000,
"blocks": 770695,
"timeoffset": 0,
"connections": 51,
"proxy": "",
"difficulty": 53205111.42544441,
"testnet": false,
"keypoololdest": 1510613968,
"keypoolsize": 999,
"paytxfee": 0.00000000,
"relayfee": 0.00010000,
"errors": ""
}

 

[UdjinM6]

WATCHDOG_EXPIRED is not an issue if you updated sentinel and have crontab enabled, should fix itself.

NEW_START_REQUIRED + "Not capable masternode: Masternode not in masternode list" is indeed an issue. Let your node to sync, wait for at least 10 minutes after you see MASTERNODE_SYNC_FINISHED and then issue start command via DMT+Trezor (make sure you are using the latest version of DMT). This should work.

 

[BitCrusher]

WATCHDOG_EXPIRED is not an issue if you updated sentinel and have crontab enabled, should fix itself.

NEW_START_REQUIRED + "Not capable masternode: Masternode not in masternode list" is indeed an issue. Let your node to sync, wait for at least 10 minutes after you see MASTERNODE_SYNC_FINISHED and then issue start command via DMT+Trezor (make sure you are using the latest version of DMT). This should work.

I think maybe I'm not waiting long enough after MASTERNODE_SYNC_FINISHED to re-run the command? Typically I watch it for about 20-30 minutes after restarting dashd (until as soon as I see MASTERNODE_SYNC_FINISHED), and try to fire it up immediately.

Should I be able to re-issue the 'Start Masternode' command/button from the Dash Masternode Tool, or do I need to restart dashd and then follow those steps? I've also tried to switch the confs previously to turn masternode=1 to masternode=0 to maybe flush whatever was previously stored (and then would switch masternode back on, restarting dashd).

I'll give this a go, and then let you know if there's a problem still.

Thank you very much for the follow-up, much appreciated as I've hit a dead end here.

 

[BitCrusher]

Update:
Here's a screenshot of the Dash Masternode Tool after clicking the start masternode button.

The outputs are the same from dashman/dashman status... with the dash masternode network state remaining blank.

It gives the NEW_START_REQUIRED status as seen in the image.
Should I shut down the dashd and restart it, re-wait for syncing and after MASTERNODE_SYNC_FINISHED, maybe wait an hour and then try to click the 'Start Masternode using Hardware Wallet' button?

Thanks again for your help.

 

[UdjinM6]

I see some MN that has invalid signature for its ping - make sure mn privkey in DMT settings matches the one in dash.conf on this specific remote node

 

[BitCrusher]

I see some MN that has invalid signature for its ping - make sure mn privkey in DMT settings matches the one in dash.conf on this specific remote node

For the private key:
I ran 'dash-cli getaccountaddress 0' on the server running dashd.
Grabbed the address and ran 'dash-cli dumpprivkey %acctaddress0%'
After that, I pasted the private key into the Dash Masternode Tool and then also used that private key in dash.conf for the masternodeprivkey= setting.
The private keys match between the dash.conf on the servers and the Dash Masternode Tool.

I've followed the same steps in previously setting up the Masternodes, we had about 3 or so payouts before the 12.2 update came out. There was also some memory/RAM issues with the server so I upgraded servers, but the same guides/steps with updated dashd, dashman, sentinel and DMT, seem to no longer work with this Trezor device.

 

[UdjinM6]

For the private key:
I ran 'dash-cli getaccountaddress 0' on the server running dashd.
Grabbed the address and ran 'dash-cli dumpprivkey %acctaddress0%'
After that, I pasted the private key into the Dash Masternode Tool and then also used that private key in dash.conf for the masternodeprivkey= setting.
The private keys match between the dash.conf on the servers and the Dash Masternode Tool.

I've followed the same steps in previously setting up the Masternodes, we had about 3 or so payouts before the 12.2 update came out. There was also some memory/RAM issues with the server so I upgraded servers, but the same guides/steps with updated dashd, dashman, sentinel and DMT, seem to no longer work with this Trezor device.

It's not exactly the way it's described in the guide but this should work too. Weird that it doesn't...
Can you send me debug.log from the remote node? [email protected] (zip it first pls)

 

[BitCrusher]

It's not exactly the way it's described in the guide but this should work too. Weird that it doesn't...
Can you send me debug.log from the remote node? [email protected] (zip it first pls)

Sent, thank you!

 

[UdjinM6]

Sent, thank you!

Received. But I found nothing weird there...

Let's try it the other way, let's follow the guide: do "dash-cli masternode genkey" and copy its output to dash.conf masternodeprivkey= settings and DMT. Make sure to restart the node to let it read this new config, give it some time to finish sync process and then issue "start" command from DMT.

 

[BitCrusher]

Received. But I found nothing weird there...

Let's try it the other way, let's follow the guide: do "dash-cli masternode genkey" and copy its output to dash.conf masternodeprivkey= settings and DMT. Make sure to restart the node to let it read this new config, give it some time to finish sync process and then issue "start" command from DMT.

Thanks, I will give it a try and let you know how it goes.

 

[BitCrusher]

Received. But I found nothing weird there...

Let's try it the other way, let's follow the guide: do "dash-cli masternode genkey" and copy its output to dash.conf masternodeprivkey= settings and DMT. Make sure to restart the node to let it read this new config, give it some time to finish sync process and then issue "start" command from DMT.

Looks like we have ENABLED now for masternode network state now. Thank you so much!
This thread can be closed.

 

[UdjinM6]

Looks like we have ENABLED now for masternode network state now. Thank you so much!
This thread can be closed.

So the difference is that "genkey" gives you an old-style uncompressed privkey (starts with '7') but I don't see why a compressed one (starts with 'X') would fail... that's weird.

Anyway... Glad that it worked