"ProTx address does not match local address"

Sven

Sven

Member
Went through the registration procedure and at first everything seemed to have gone fine. No errors and MN showed up in the DIP3 Masternodes tab in Dash Core wallet and showed ENABLED. Great! Went to get something to eat and came back to find "SENTINEL_PING_EXPIRED". Crap!

Trying to relaunch Sentinel on the VPS:
Code: 
Invalid Masternode Status, cannot continue.

Checked masternode status on the VPS, it shows:
Code: 
"status": "Not capable masternode: Masternode collateral is a ProTx and ProTx address does not match local address"

Doublechecked the collateral address. It's definitely correct and has been running on this address for a long time. Something wrong with the owner/votingKeyAddr? I tried to redo the registration with a new one via getnewaddress on my Dash Core wallet. After the last step (sending the new protx register_submit), I get:
Code: 
bad-protx-dup-key (code 18) (code -1)

Now I'm stuck. Any help?

EDIT: On the My Masternodes tab, it now shows EXPIRED. Dash Ninja also shows EXPIRED. But on the DIP3 Masternodes tab, it still shows ENABLED. Which one is it?

EDIT 2: I just noticed on the My Masternodes tab, it shows a different IP address than when I click on the Show Info... button on the bottom for the same MN. The Show Info... button matches what's in masternode.conf, the overview list on the My Masternodes tab doesn't.

EDIT 3: And on the VPS, the output of masternode status shows an outpoint and payee that doesn't match the masternodeprivkey in dash.conf. That is, those outpoint (= collateral transaction) and payee belong together, but they are from a different MN than what's specified in dash.conf via masternodeprivkey.
 
Last edited:
Sven said:
Went through the registration procedure and at first everything seemed to have gone fine. No errors and MN showed up in the DIP3 Masternodes tab in Dash Core wallet and showed ENABLED. Great! Went to get something to eat and came back to find "SENTINEL_PING_EXPIRED". Crap!

Trying to relaunch Sentinel on the VPS:
Code: 
Invalid Masternode Status, cannot continue.

Checked masternode status on the VPS, it shows:
Code: 
"status": "Not capable masternode: Masternode collateral is a ProTx and ProTx address does not match local address"

Doublechecked the collateral address. It's definitely correct and has been running on this address for a long time. Something wrong with the owner/votingKeyAddr? I tried to redo the registration with a new one via getnewaddress on my Dash Core wallet. After the last step (sending the new protx register_submit), I get:
Code: 
bad-protx-dup-key (code 18) (code -1)

Now I'm stuck. Any help?
Click to expand...

Try this in your Linux server (copy and paste) :

for n in `./dash-cli protx list|head -n -1|tail -n +2` ; do n=${n//\"/} ; ./dash-cli protx info ${n//,} ; done | grep service|sort

This will give you all DIP3 masternodes with their IP Address
Copy the whole list and paste it into notepad++ and search for your ipaddress, is it in that list ?
Then you at least know if your masternode got registered as a DIP3 masternode correctly.

Note : when doing a restart of dashd the masternode normally hangs in a Sentinel Ping Expired state for awhile before showing ENABLED.
But it should not take longer then 30 minutes i think.

Use this command to check from time to time : ./dash-cli masternode list full | grep -e IPADDRESS (replace with your mn ip address).
You either get to see Sentinel Ping Expired warning and need to wait a bit longer or you see "ENABLED"

Note : the ENABLED status from your DIP3 masternode does not correlate with the status on your masternodes tab, they are two seperate status.
Which means that you can see "ENABLED" in your DIP3 tab and Sentinel Ping Expired on your masternodes tab / dashninja / server. Sentinel Ping Expired should in the end change to ENABLED also.
Once Spork 15 activates only the DIP3 tab with its status will remain i think.
 
Last edited:
The MN is in the DIP3 list.

As I wrote, the MN had already been on ENABLED status for a while, both in the DIP3 and the My Masternodes list. Then it went back to SENTINEL_PING_EXPIRED, then to EXPIRED (see Edit 1) on the My Masternodes tab. Now it shows NEW_START_REQUIRED. Such backwards regression is definitely not normal.

I'm also at a loss to explain the other phenomena in my edits 2 and 3.
 
Sven said:
The MN is in the DIP3 list.

As I wrote, the MN had already been on ENABLED status for a while, both in the DIP3 and the My Masternodes list. Then it went back to SENTINEL_PING_EXPIRED, then to EXPIRED (see Edit 1) on the My Masternodes tab. Now it shows NEW_START_REQUIRED. Such backwards regression is definitely not normal.

I'm also at a loss to explain the other phenomena in my edits 2 and 3.
Click to expand...

Well, as last resort you could :

A : From your hot wallet / VPS server : stop dashd, delete mncache.dat and restart dashd and see if it still shows NEW_START_REQUIRED (i had a few false NEW_START_REQUIRED messages fixed this way in the past)
B : From your cold wallet : delete mncache and peers.dat files and restart to see if that fixes anything with regards to your edit 2 & 3 (maybe even delete all those dat.files there except ofc your wallet.dat)
C : search through your debug.log and see if anything sticks out

I suspect you get the "bad-protx-dup-key (code 18) (code -1)", because it needs a ProUpRegTx or a ProUpRevTx, not a new ProRegTx command.
See : https://docs.dash.org/en/stable/masternodes/maintenance.html (section : Updating Masternode Information)
 
Last edited:
Yesterday I already did, all on my local machine: close Dash Core, delete all *.dat files except wallet.dat, relaunch Dash Core.

At first, it showed the MN with the correct IP as specified in the masternode.conf file on the My Masternodes tab. Status was MISSING. Then, as it rebuilt various caches and databases, it switched in front of my eyes to the wrong IP again (see Edit 2 in OP) with status EXPIRED.

I'll try the same procedure on the server. Let's see.
 
Update:
Almost embarrassed to admit, I hadn't restarted the MN yet. I mean I relaunched the software, but hadn't issued the "Start alias" command yet. Did that now and everything resolved itself. The IPs switched back and the MN is now ENABLED. I lost my spot in line I guess, but at least it's working again. :)

Still curious how this could get messed up in the first place.

Going through this ordeal made me wonder if the software uses different items as identifier at the various places a MN needs to be identified. Sometimes via IP, sometimes via collateral tx, sometimes via payout address. To make it more confusing, the are called different things at different places, e.g. tx ID vs. hash. If that's the case, does DIP3 also clean that up a bit?
 
Last edited:
Sven said:
Update:
Almost embarrassed to admit, I hadn't restarted the MNs yet. I mean I relaunched the software, but hadn't issued the "Start alias" command yet. Did that now and everything resolved itself. The IPs switched back and both MNs are now ENABLED. I lost my spot in line I guess, but at least it's working again. :)

Still curious how this could get messed up in the first place.

Going through this ordeal made me wonder if the software uses different items as identifier at the various places a MN needs to be identified. Sometimes via IP, sometimes via collateral tx, sometimes via payout address. To make it more confusing, the are called different things at different places, e.g. tx ID vs. hash. If that's the case, does DIP3 also clean that up a bit?
Click to expand...

Should do, until spork 15 activates the network is (sort of) running 2 types of configuration simultaneously and there's a bit of cleanup work that can be done afterwards, for example masternode.conf will be obsolete and a few entries can be removed from dash.conf.

Some of your earlier issues may have been related to old configs hanging around on the network. Because it's p2p nodes have to keep records of other nodes, they clear out those records with time but there has to be a fairly long delay. As far as I know the ProTx method addresses that and changes should propagate as quickly as transactions but don't quote me on it, they should certainly make things simpler once spork 15 is in :)
 
Management of status will be a lot simpler in the new DIP3 list. I think the confusion here that one list was showing errors while the other said "ENABLED". The lists are unrelated, just because you have fulfilled the requirements to be recongised by the DIP3 list does not mean you have e.g. set up sentinel correctly and issued the start command to stay on the old non-deterministic list. Unfortunately this is a difficulty during the "compatibility mode" changeover period, where you need to jump through the hoops to remain on both lists in order to continue providing serve, and thus to get paid.
 
You must log in or register to reply here.
Back
Top