dashd vers 0.14 dash-cli masternodelist addr does not report the address

[demodun6]

This issue tracker is only for technical issues related to Dash Core.

General Dash questions and/or support requests and are best directed to the Dashpay Reddit.

To report critical security issues, email infosec@dash.org and/or see the DASH bug bounty program on Bugcrowd instead of creating Github issues.

Describe the issue

Reported also in https://www.dash.org/forum/threads/dash-watch-renewal-pre-proposal-april-15-2018.36411/page-2#post-211966

dash-cli masternodelist addr|grep edee2b80e5a450b144a655e65c9e3cb81ff4fb4324dc87a6e602a4619fa5887a-1

"edee2b80e5a450b144a655e65c9e3cb81ff4fb4324dc87a6e602a4619fa5887a-1": "[0:0:0:0:0:0:0:0]:0",

Can you reliably reproduce the issue?

yes

If so, please list the steps to reproduce below:

dash-cli masternodelist addr|grep edee2b80e5a450b144a655e65c9e3cb81ff4fb4324dc87a6e602a4619fa5887a-1

"edee2b80e5a450b144a655e65c9e3cb81ff4fb4324dc87a6e602a4619fa5887a-1": "[0:0:0:0:0:0:0:0]:0",

Expected behaviour

Tell us what should happen

Show the IP address of edee2b80e5a450b144a655e65c9e3cb81ff4fb4324dc87a6e602a4619fa5887a-1

Actual behaviour

Tell us what happens instead shows "edee2b80e5a450b144a655e65c9e3cb81ff4fb4324dc87a6e602a4619fa5887a-1": "[0:0:0:0:0:0:0:0]:0",

Screenshots.

If the issue is related to the GUI, screenshots can be added to this issue via drag & drop.

What version of Dash Core are you using?

List the version number/commit ID, and if it is an official binary, self compiled or a distribution package such as PPA.

DashCore v0.14

[demodun6]

dash-cli getinfo { "version": 140000, "protocolversion": 70214, "walletversion": 61000, "balance": 0.00000000, "privatesend_balance": 0.00000000, "blocks": 1075994, "timeoffset": 0, "connections": 15, "proxy": "", "difficulty": 134104222.3376396, "testnet": false, "keypoololdest": 1540288958, "keypoolsize": 999, "paytxfee": 0.00000000, "relayfee": 0.00001000, "errors": "" }

Another way to produce the bug is this:

dash-cli masternodelist addr|grep -v 9999

{ "edee2b80e5a450b144a655e65c9e3cb81ff4fb4324dc87a6e602a4619fa5887a-1": "[0:0:0:0:0:0:0:0]:0", }

[schinzelh]

I can confirm the issue - actually it is a node i was hosting and i revoked the registration two days ago, using protx revoke - it seems like masternodelist keeps these entries with operator pubkey all 0s and IP [0:0:0:0:0:0:0:0]:0

$ dash-cli protx info 20f7bbf6965602c971431f1542cbf4930d69020d6a5593480f1aae231d8169c7
{
  "proTxHash": "20f7bbf6965602c971431f1542cbf4930d69020d6a5593480f1aae231d8169c7",
  "collateralHash": "edee2b80e5a450b144a655e65c9e3cb81ff4fb4324dc87a6e602a4619fa5887a",
  "collateralIndex": 1,
  "collateralAddress": "XwHey2Yf8vmYG19fpsWeHWsbDKZ8n7sCGU",
  "operatorReward": 0,
  "state": {
    "service": "[0:0:0:0:0:0:0:0]:0",
    "registeredHeight": 1031340,
    "lastPaidHeight": 1070946,
    "PoSePenalty": 0,
    "PoSeRevivedHeight": -1,
    "PoSeBanHeight": 1075115,
    "revocationReason": 1,
    "ownerAddress": "XbowwTJCU4cifbJJZ5ysk2J2WSTKQ8BGdU",
    "votingAddress": "XbowwTJCU4cifbJJZ5ysk2J2WSTKQ8BGdU",
    "payoutAddress": "XwHey2Yf8vmYG19fpsWeHWsbDKZ8n7sCGU",
    "pubKeyOperator": "000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
  },
  "confirmations": 44685,
  "wallet": {
    "hasOwnerKey": false,
    "hasOperatorKey": false,
    "hasVotingKey": false,
    "ownsCollateral": false,
    "ownsPayeeScript": false,
    "ownsOperatorRewardScript": false
  }
}

$ dash-cli masternode status
{
  "outpoint": "0000000000000000000000000000000000000000000000000000000000000000-4294967295",
  "service": "82.211.21.191:9999",
  "proTxHash": "20f7bbf6965602c971431f1542cbf4930d69020d6a5593480f1aae231d8169c7",
  "collateralHash": "edee2b80e5a450b144a655e65c9e3cb81ff4fb4324dc87a6e602a4619fa5887a",
  "collateralIndex": 1,
  "dmnState": {
    "service": "82.211.21.191:9999",
    "registeredHeight": 1031340,
    "lastPaidHeight": 1070946,
    "PoSePenalty": 0,
    "PoSeRevivedHeight": -1,
    "PoSeBanHeight": -1,
    "revocationReason": 0,
    "ownerAddress": "XbowwTJCU4cifbJJZ5ysk2J2WSTKQ8BGdU",
    "votingAddress": "XbowwTJCU4cifbJJZ5ysk2J2WSTKQ8BGdU",
    "payoutAddress": "XwHey2Yf8vmYG19fpsWeHWsbDKZ8n7sCGU",
    "pubKeyOperator": "84561ca14c2e458177512d8566dff46accf6b38b356274fd884b0c63856e8d1b3a24c8ece117385435634443e03adfa0"
  },
  "state": "REMOVED",
  "status": "Masternode removed from list"
}

[UdjinM6]

Masternode was revoked i.e. operator stopped maintaining the node and providing service to the network at height 1075115, so operator related fields were reset. But owner did nothing - collateral is not spent, so MN is still kind of there. Works as designed :)

[demodun6]

Work as designed maybe, but this design is buggy because it defies common sense. When we ask for an IP address, an IP address should be given. This "[0:0:0:0:0:0:0:0]:0" is not an IP address.

If the core team insists of keeping information about "Masternodes without IP address" (although I still wonder how something without IP can be named a Masternode), maybe they should create another command:

dash-cli masternodelist withoutaddr

[thephez]

There is no IP address to provide in this case (thus the "null" IP/port). If an operator revokes their key and ceases to host the MN, the owner must submit a ProUpRegTx to assign it to a new operator as described in DIP3. That new operator is then responsible for providing the hosting details (i.e. IP address). This allows MNOs to change hosting services without having to re-register the MN or touch the collateral at all. It also allows operators to manage the hosting details independent of the owner (e.g. the operator can change IPs without the owner needing to do anything).

[demodun6]

@thephez Whatever you said is correct, but all your arguments are irrelevant to the command.
dash-cli masternodelist addr This command is supposed to give a list of masternodes, together with their IPs. A list of IP adresses is what the end user expects. "[0:0:0:0:0:0:0:0]:0" is not even an IP address. At least make it "0.0.0.0:0"

[thephez]

@demodun6 As per DIP3, the IP address field is sized to be compatible with future IPv6 support - thus the colons and 8 digits (standard IPv6 way of representing addresses). The :0 at the end is the port.

[demodun6]

I confirm that I am vazaki2@dashtalk, and whoever else vazaki2 claims I am.

[demodun6]

@thephez you have a point on that...

[PastaPastaPasta]

This issue has been resolved. Closing.