feat(dash-spv): add fixed testnet peer IP fallbacks (68.67.122.1-29)

[QuantumExplorer]

Summary

DNS discovery alone may not return testnet peers in every environment. Adds the 29 fixed HP-masternode testnet IPs (68.67.122.1 — 68.67.122.29) as a fallback that is always included in testnet peer discovery alongside DNS results.

Extracted from

Cherry-picked from feat/platform-wallet2 (draft PR #655) so it can land independently.

Test plan

• cargo build -p dash-spv --all-features
• cargo test -p dash-spv --all-features --lib discovery — 1 passed / 0 failed (+2 ignored, unrelated)
• Two-file change (dash-spv/src/network/constants.rs, dash-spv/src/network/discovery.rs, +44 / −1).

🤖 Extracted with Claude Code

[coderabbitai]

Warning

Rate limit exceeded

@QuantumExplorer has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 58 minutes and 26 seconds before requesting another review.

Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 58 minutes and 26 seconds.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 7710bcb5-ad07-46f3-ad4b-7002281130d3

📥 Commits

Reviewing files that changed from the base of the PR and between e15ea34 and bcb0a51.

📒 Files selected for processing (2)

• dash-spv/src/network/constants.rs
• dash-spv/src/network/discovery.rs

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/testnet-peer-fallback-ips

---

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.}

[codecov]

Codecov Report

❌ Patch coverage is 0% with 7 lines in your changes missing coverage. Please review.
✅ Project coverage is 68.10%. Comparing base (e15ea34) to head (bcb0a51).

Files with missing lines	Patch %	Lines
dash-spv/src/network/discovery.rs	0.00%	7 Missing ⚠️

Additional details and impacted files

@@              Coverage Diff              @@
##           v0.42-dev     #658      +/-   ##
=============================================
+ Coverage      68.08%   68.10%   +0.02%     
=============================================
  Files            319      319              
  Lines          67646    67652       +6     
=============================================
+ Hits           46057    46077      +20     
+ Misses         21589    21575      -14     

Flag	Coverage Δ
core	75.52% <ø> (ø)
ffi	37.94% <ø> (ø)
rpc	20.00% <ø> (ø)
spv	85.96% <0.00%> (+0.10%)	⬆️
wallet	68.08% <ø> (ø)

Files with missing lines	Coverage Δ
dash-spv/src/network/discovery.rs	27.39% <0.00%> (-2.46%)	⬇️

... and 5 files with indirect coverage changes

[ZocoLini]

Is this being an issue in your branch?? Hardcoding peers will hide dns bugs that may be introduced in a future

[xdustinface]

I think the reason why ivan added this is because he ended up with peers without required capabilities. Im working on some improvements there to make sure we keep searching for capable peers instead of being stuck with our connected incapable peers.

Generally i think it might be a good idea to have fallback peers, not only for testnet probably also some hardcoded one for mainnet would be useful just in case but i dont think we should just inject them in the DNS lookup code, seems weird.

We should probably rather add them in the network maintainance loop if the DNS actually fails / we have trouble to find peers then we should use the fallback?

[QuantumExplorer]

@xdustinface @ZocoLini the thing is that for testnet these are the ips of the peers and they will never change. We bought the ip addresses. I don't see a way they could ever change as long as we have funding to maintain testnet. So why even have seed discovery? It will slow down the process for no tangible benefit.

[xdustinface]

I don't see a way they could ever change as long as we have funding to maintain testnet. So why even have seed discovery?

One reason to have it and only use the hardcoded as fallback in case of DNS failure would be that we then use the same way into the network in both main/testnet and so we don't hide issues. If we in testnet always just connect straight away to a good set of nodes we probably don't really run much through all the peer discovery, capabilitiy filtering and reconnection paths to get to a good set of peers.

We probably also have no good test coverage for all that. So it's good to run this stuff when using testnet.

It will slow down the process for no tangible benefit.

What do you mean is slow? The only time i had trouble with the DNS was when the seeder got taken down for two days last months but usually its not slow or any problem for me, or did you have trouble with it?

What currently is still annoying: we don't really try to end up with peers that match our required capabilities so we can end up in a state where we are stuck because we don't have peers that support compact filters but im working on that one currently.

[QuantumExplorer]

One reason to have it and only use the hardcoded as fallback in case of DNS failure would be that we then use the same way into the network in both main/testnet and so we don't hide issues. If we in testnet always just connect straight away to a good set of nodes we probably don't really run much through all the peer discovery, capabilitiy filtering and reconnection paths to get to a good set of peers.

This is true only if we never tested mainnet.

The reason for this work was that the DNS seed was not working.

DNS seeds represent an element on centralization that we don't want. Time has given us the wisdom that it's much better to hardcode a list of peers than it is to rely on a seeder.