Fix display issues for IPv6 proxy setup in Options Dialog (UI only, no functionality impact)

[pablomartin4btc]

Currently, setting up a proxy (whether SOCKS5 or Tor) with an IPv6 address works correctly via the command line or configuration file in both bitcoind and bitcoin-qt (also from the UI the ipv6 address gets saved properly in settings.json). However, the UI does not reflect this properly, which can create confusion. Since some ISPs and VPNs still experience issues with IPv6, users may mistakenly think there is a problem with Bitcoin Core, when in fact the proxy setup is functioning as expected.

So this PR ensures that the proxy IP is displayed correctly in the UI when using an IPv6 address.

No functionality impact; changes only affect UI display.

Click her to see before and after screenshots.

• Before:

  

• After:

  

---

Test instructions

(Ubuntu 22.04)

1. Start ssh service on localhost.

   ssh -D [::1]:1080 -f -C -q -N localhost

2. Check that the service is up and running.

   ps aux | grep ssh
   pepe    2860289  0.0  0.0  20456  5576 ?        Ss   06:59   0:00 ssh -D [::1]:1080 -f -C -q -N localhost
   

3. Check with bitcoind if it works correctly.

   bitcoind -onlynet=ipv6 -proxy=[::1]:1080

4. Check for established connections.

   netstat -natl |grep 1080
   tcp6       0      0 ::1:1080                :::*                    LISTEN     
   tcp6       0      0 ::1:47610               ::1:1080                ESTABLISHED
   tcp6       0      0 ::1:1080                ::1:47610               ESTABLISHED
   tcp6       0      0 ::1:1080                ::1:47606               TIME_WAIT    
   

   [
      {
        "id": 0,
        "addr": "[2a01:4f9:4a:2a07::2]:8333",
        "addrbind": "[::1]:47638",
        "network": "ipv6",
   ...
   

5. Stop bitcoind and run bitcoin-qt adding the corresponding configuration in settings.json.

   {
      "onlynet": "ipv6",
      "proxy": "[::1]:1080",
   }
   

6. Open the Peers window to check available connections or run getpeerinfo on the rpc-console window.

7. Same can be done for Tor setting up tor service (I'll add instructions later) and configuring on its default port 9050 and forcing "onlynet": "onion" to verify easily the net traffic.

---

Thanks jarolrod and vasild for your help on validating ipv6 was not broken.

[DrahtBot]

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Reviews

See the guideline for information on the review process.

Type	Reviewers
ACK	vasild, promag, hebasto

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

[DrahtBot]

🚧 At least one of the CI tasks failed.
_{Debug: https://github.com/bitcoin-core/gui/runs/30169388972}

Hints

Make sure to run all tests locally, according to the documentation.

The failure may happen due to a number of reasons, for example:

• Possibly due to a silent merge conflict (the changes in this pull request being
  incompatible with the current code in the target branch). If so, make sure to rebase on the latest
  commit of the target branch.

• A sanitizer issue, which can only be found by compiling with the sanitizer and running the
  affected test.

• An intermittent issue.

Leave a comment here, if you need help tracking down a confusing failure.

[vasild]

The changes to src/qt/optionsmodel.cpp look ok to me.

[vasild]

Approach ACK a7d8de9

[vasild]

SplitHostPort() returns "true if port-portion is absent or within its allowed range". Here we want the port to be present and with its allowed range. So if we check that SplitHostPort() is true, that is not sufficient. For our usecase SplitHostPort() must be true and the port must be present. How to check whether the port is present? That would be port != 0. So that condition should be:

Suggested change

	if (!SplitHostPort(proxy.toStdString(), port, hostname) || port != 0) {
	if (SplitHostPort(proxy.toStdString(), port, hostname) && port != 0) {
	// valid and port is present and within the valid range

If there is a bug in SplitHostPort() that should be fixed separately.

[pablomartin4btc]

After playing with the function and the tests (netbase_tests - TestSplitHost - & net_tests - addr.IsValid()), what you propose looks more correct/ understandable to me as the use cases we were looking at were "::1:1080" (which passed to SplitHostPort() returns valid/ true and port 0) vs "[::1]:1080" (returning true and port 1080).

If there is a bug in SplitHostPort() that should be fixed separately.

I think it's clear to me now that if you have multiple ":" it's because it's an ipv6 address and in that case you need to use the brackets to separate it from the port as [ipv6]:port otherwise the split will be ignored and the function will return the whole thing as the hostname (check other cases in TestSplitHost). Perhaps we can add these 2 cases in the tests so there's no confusion in the future (but there are similar cases with different values).

BOOST_CHECK(TestSplitHost("::1:1080", "::1:1080", 0, true));
BOOST_CHECK(TestSplitHost("[::1]:1080", "::1", 1080, true));

[pablomartin4btc]

Updates:

• Addressed @vasild's feedback.

[vasild]

ACK fee4cba

[promag]

Code review ACK fee4cba.

[hebasto]

ACK fee4cba, I have reviewed the code and it looks OK.