"ProTx address does not match local address"

Sven

Member
Masternode Owner/Operator
Aug 15, 2017
47
12
48
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:

qwizzie

Well-known Member
Aug 6, 2014
1,661
799
183
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?
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:

Sven

Member
Masternode Owner/Operator
Aug 15, 2017
47
12
48
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.
 

qwizzie

Well-known Member
Aug 6, 2014
1,661
799
183
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.
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:

Sven

Member
Masternode Owner/Operator
Aug 15, 2017
47
12
48
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.
 

Sven

Member
Masternode Owner/Operator
Aug 15, 2017
47
12
48
This is very bizzare. I doublechecked masternode.conf on my local machine and dash.conf on the servers. For clarity, this involves two masternodes, let's call them 1 and 2.
  • My local masternode.conf file has lines for MN1 at IP1 with PrivKey1 and CollateralTx1 as well as for MN2 at IP2 with PrivKey2 and CollateralTx2.
  • Blockexplorer confirms CollateralTx1 paid into PayoutAddr1 and CollateralTx2 paid into PayoutAddr2.
  • VPS1 runs on IP1 and dash.conf on VPS1 specifies PrivKey1.
  • VPS2 runs on IP2 and dash.conf on VPS2 specifies PrivKey2.
  • I still have the text doc open where I prepared the protx register_prepare command for both MNs. Using undo, I could see what I had entered and I can confirm that I issued one command with CollateralTx1, IP1, PayoutAddr1 and another one with CollateralTx2, IP2, PayoutAddr2 (+ the other data like voting keys etc.)
Both MNs have been running smoothly for months. Now, when I delete .dat files (except wallet.dat) from my local machine and relaunch Dash Core, at the My Masternodes tab, it first lists MN1 with IP1 and PayoutAddr1 as well as MN2 / IP2 / PayoutAddr2, status MISSING as mentioned earlier. That's as it should be. But when the progress bar on the bottom is halfway through "Synchronizing masternodes...", the listing suddenly switches to MN1 / IP2 / PayoutAddr1 and MN2 / IP1 / PayoutAddr2 both with status ENABLED. When the progress bar is going through "Synchronizing masternode payments...", the status for MN1 switches to NEW_START_REQUIRED while MN2 to remains ENABLED.

(Dash Ninja also showed one MN as ENABLED, but it listed PayoutAddr1 with IP2. Dash Ninja doesn't know my MN aliases, so I'm not even sure if that refered to MN1 or MN2. What's used as identifier here, the IP or the PayoutAddr?)

Double-clicking on the "MN1 / IP2 / PayoutAddr1" listing (or clicking the Show Info button) shows in a separate window: MN1, PrivKey1, CollateralTx1, IP1, PayoutAddr1. The same info window for the "MN2 / IP1 / PayoutAddr2" listing shows MN2, PrivKey2, CollateralTx2, IP2, PayoutAddr2. Note how in the info window, the IPs are as they should be, but they're swapped in the main listing.

On the DIP3 Masternodes tab, I can find on the list:
IP1 with PayoutAddr1 and also IP2 with PayoutAddr2. Both show as ENABLED. The IP-PayoutAddr pairing is correct here.

Now I also deleted .dat files from VPS1 and VPS2 and restarted dashd on both. That caused MN2 on the Dash Core My Masternodes tab to switch to EXPIRED and wmasternode status on VPS1 shows:
Code:
"outpoint": "0000000000000000000000000000000000000000000000000000000000000000-4294967295",
  "service": "[IP1]:9999",
  "status": "Not capable masternode: Masternode in NEW_START_REQUIRED state"
and on VPS2, it shows:
Code:
"outpoint": "0000000000000000000000000000000000000000000000000000000000000000-4294967295",
  "service": "[IP2]:9999",
  "status": "Not capable masternode: Masternode collateral is a ProTx and ProTx address does not match local address"
Dash Ninja now shows for the two nodes:
  • CollateralTx1 / PayoutAddr1 / IP2 / EXPIRED
  • CollateralTx2 / PayoutAddr2 / IP1 / NEW_START_REQUIRED
Notice IPs are still swapped here. Now I double-checked conf files and restarted local and remotely. I'm at the end of my wits.
 
Last edited:

Sven

Member
Masternode Owner/Operator
Aug 15, 2017
47
12
48
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?
 
Last edited:

stan.distortion

Well-known Member
Oct 30, 2014
903
526
163
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?
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 :)
 

strophy

Administrator
Dash Core Team
Moderator
Dash Support Group
Feb 13, 2016
751
437
133
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.
 
  • Like
Reactions: stan.distortion

Sven

Member
Masternode Owner/Operator
Aug 15, 2017
47
12
48
My confusion was mainly that IP addresses that the MNs insisted on running on didn't match the config files. That was resolved with the restart command. But yes, the two different lists, one ENABLED, one not, added to the confusion.