#36170 net: require a dedicated bind for automatic Tor

• Prevent incoming Tor connections from misclassifying as direct IP traffic or inheriting proxy permissions
• Require nodes with custom bind setups to specify a dedicated onion bind instead of falling back to standard binds

This PR requires that nodes using explicit `-bind` configurations specify a dedicated onion bind (`-bind=<addr>=onion`) when automatic Tor onion services are enabled (`-listenonion`). If no dedicated onion bind is provided, the node will refuse to start instead of routing incoming onion connections to the first normal P2P bind.

Problem: When the automatic onion service lacks a dedicated onion bind, incoming Tor connections forward to a normal P2P bind. The node cannot differentiate these from direct IP connections, leading to incorrect peer network classification and potentially granting anonymous Tor peers permissions associated with the Tor proxy IP.

P3 · bug fix

• P3 because it prevents incoming Tor connections from accidentally inheriting localhost whitelist permissions
• Affects only nodes running custom bind configurations and is reasonably deferrable

Prevents accidental privilege inheritance for incoming Tor connections on custom `-bind` setups where peers might otherwise inherit localhost whitelist permissions. The scenario is specific to custom node configurations and reasonably deferrable.

Membership: Modifies P2P listener configuration and bind enforcement to ensure correct network identification and permissions for incoming Tor connections.

Factors: security/stability 2, bug 1, performance 0, user value 1, leverage 0

• Ready to review
• Open discussion on whether to disallow wildcard onion binds is a scoping choice, not rework

The patch is small and functional. Open questions regarding whether to disallow wildcard onion binds are scoping discussions rather than pending rework that would invalidate a review.

Author status: silent since 2026-09-04

Open concerns:

• jeanpablojp noted that `-bind=0.0.0.0:8334=onion` passes the check while failing to tag connections properly, and asked whether disallowing wildcard onion binds is in scope.
• jeanpablojp suggested updating documentation in doc/tor.md and simplifying test assertions.

• Supportive sentiment with minor open questions on scope and documentation
• Concept approval while raising an edge case on wildcard onion binds (jeanpablojp)
• Approach approval without objections (winterrdog)

Positive: Concept ACK from jeanpablojp and Approach ACK from winterrdog without objections.

Reviewers support the approach recommended in prior issue discussion (#34892), with minor open questions regarding scope and documentation.

• jeanpablojp: Concept ACK and raised an edge case regarding wildcard onion binds.
• winterrdog: Approach ACK.

Review verdicts (DrahtBot): 0

• Approach ACK: winterrdog
• Concept ACK: jeanpablojp

22 lines under test/bench/ci.

• src/init.cpp +10/-8
• test/functional/feature_bind_extra.py +11/-1
• doc/release-notes-36170.md +9/-0
• test/functional/feature_proxy.py +5/-2
• test/functional/feature_torcontrol.py +2/-0
• test/functional/p2p_private_broadcast.py +1/-0

• Whether the author will choose to expand the scope to disallow wildcard onion binds like 0.0.0.0.

PR 36170 requires a dedicated onion bind option (-bind=<addr>=onion) whenever explicit -bind arguments are passed and automatic Tor listening is active, refusing startup otherwise. This prevents Tor connections from arriving on standard binds where they cannot be differentiated from direct IP connections and might inherit unintended whitelist privileges. The change is small, follows recommendations from #34892, and has an Approach ACK from winterrdog and a Concept ACK from jeanpablojp with open questions about wildcard bind edge cases.