fix: Guard mnauth by local masternode service

[UdjinM6]

A node can be bound to multiple addresses. Send mnauth to nodes connected to the right address only to avoid confusion.

Thanks @kxcd 👍

[PastaPastaPasta]

I'm pretty sure I'd like some tests on this one please :)

[kxcd]

I can test it on testnet, just get me a build.

[UdjinM6]

I can test it on testnet, just get me a build.

You should be able to download it from CI build artefacts e.g. https://gitlab.com/dashpay/dash/-/jobs/2893007730/artifacts/browse/build-ci/dashcore-linux64/src/dashd for linux64-build

[kxcd]

404 on that link, I am guessing because the build failed, I will check back later.

[UdjinM6]

404 on that link, I am guessing because the build failed, I will check back later.

oh, sorry, my bad
results (../browse/..): https://gitlab.com/dashpay/dash/-/jobs/2893007730/artifacts/browse/build-ci/dashcore-linux64/src/
link to dashd (../file/..): https://gitlab.com/dashpay/dash/-/jobs/2893007730/artifacts/file/build-ci/dashcore-linux64/src/dashd

[MrDefacto]

What about nodes that uses local addresses to bind? Local IP that is translated 1:1 to public? There are certain DMZ setup or other cases when nodes are running like that.
There bind address doesn't match MN registered service IP.

EDIT: of course externalip is set to public ip

[kxcd]

My test will be on a node whose P2P is port forwarded into the VM, so I assume the dashd will bind to some private address eg, 10.x.y.z however, I believe it is still a condition that a Masternode specify the correct externalip= paramater to work and as such if this patch fails, maybe the comparison should be done against that property?

[PastaPastaPasta]

Just for clarity, I'm asking for functional tests

[kxcd]

I tested this fix first with my Masternode configured for TOR, I then checked on a node with onlynet=onion and another node without TOR, the result was that on the onion network, the the MN was not disclosed and on the plain net node, it was shown as a verified MN as expected. From the logs, the top IPs that were not the same as mine where.

Num   IP
914 185.220.100.243
856 185.220.100.255
732 185.220.100.241
707 185.220.100.253
705 185.220.100.252

and
358 ::
and a few IPv6 IPs. Are these IPs TOR node IPs?
I then re-ran the test with no masternode connected to TOR and checked the log and the message still prints, I got 294 hits for :: in about 30 mins. All my masternodes are connected on behind a NAT F/W and presumably bind to a private IP. I was not able to test on VM with a public IP at this time. Just one thing, the log message says 'differents' instead of 'different', otherwise this fix seems to work.

[thephez]

@PastaPastaPasta @UdjinM6 Are we planning to merge this at some point? It's still assigned to the 18.2 milestone

[PastaPastaPasta]

I'm not sure... I'd really like to see a functional test on this, but if we let it sit this long w/o adding a test we may have to wait a very long time before Udjin or I decide to write the test. That makes me inclined to be okay merging it. Any thoughts Udjin?

[UdjinM6]

I'm not sure how to make it testable cause local addresses aren't passed via version message, only routable ones are... Squashed and reworked the fix a bit - you can change https://github.com/dashpay/dash/pull/4974/files#diff-0f59ac68e534009ef1063c98c5df0b13d16771ad367cfae36850f5f2fc035d1fR34 to smth else (e.g. 127.0.0.2) and all mn-related tests should fail. That's probably the best option I have in my mind 🤷

EDIT: @kxcd could you test the new version on your nodes pls?

[github-actions]

This pull request has conflicts, please rebase.

[knst]

Is it still relevant? Can it be merged without tests?

[DashCoreAutoGuix]

❌ Backport Verification - Not Applicable

This PR is not a Bitcoin backport - it contains Dash-specific functionality and should not be processed by the backport verification system.

Original Bitcoin commit: (none - Dash-specific change)
Reviewed commit hash: 4ddda42324-verify-1753721929

Analysis:

• This PR implements Dash-specific masternode functionality (mnauth, DML)
• It addresses masternode authentication for nodes bound to multiple addresses
• This is native Dash development, not a Bitcoin Core backport

Recommendation:
This PR should be reviewed through the standard Dash development process, not the backport verification workflow. The backport verification system is specifically designed for Bitcoin Core backports.

Note: If this PR was incorrectly labeled as a backport, please remove any backport-related labels and process it as a native Dash enhancement.

[github-actions]

✅ No Merge Conflicts Detected

This PR currently has no conflicts with other open PRs.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 39cae648-42c1-416e-a3a0-583fb5bfb5a4

📥 Commits

Reviewing files that changed from the base of the PR and between d1eab6c and 20c6139.

📒 Files selected for processing (3)

• src/evo/mnauth.cpp
• test/functional/p2p_mnauth.py
• test/functional/test_runner.py

---

Walkthrough

This pull request modifies the masternode authentication flow to add service address validation for inbound peer connections. The change in src/evo/mnauth.cpp caches the pro transaction hash and adds a check: when an inbound peer connects, it compares the peer's bound service address against the expected service from the masternode's active manager. If they differ, the code logs a message and returns without sending the MNAUTH message. A new functional test file validates this behavior by attempting connections to both the registered masternode service and an alternate local bind address, verifying that MNAUTH is only sent for the expected service address.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~15 minutes

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main change: guarding mnauth by verifying the local masternode service address matches the peer's connection address.
Description check	✅ Passed	The description is directly related to the changeset, explaining that mnauth should only be sent to nodes connected on the correct address to avoid confusion when a node is bound to multiple addresses.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[thepastaclaw]

Code Review

Clean mnauth service guard implementation. The new check correctly compares the accepted socket local endpoint (peer.addrBind) against the active masternode registered service, properly handling multi-homed inbound connections. Functional test covers both the expected-service and alternate-bind paths for v1/v2 transport.

Reviewed commit: 20c6139

[PastaPastaPasta]

MNList now supports multiple core p2p addresses, we should acknowledge that here and use that.

[thepastaclaw]

✅ Review complete (commit 20c6139)

[UdjinM6]

MNList now supports multiple core p2p addresses, we should acknowledge that here and use that.

That's true for MNList but masternodes themselves are single-address today - see CService m_service which is assigned via GetLocalAddress() and checked against dmn->pdmnState->netInfo->GetPrimary() in CActiveMasternodeManager::InitInternal(). If/when the active MN manager gains multi-address awareness, the MNAUTH guard should be updated to match it too - but that's a broader change beyond the scope of this fix.