bitcoind shouldn’t perform network activity if the option networkactive=0, e.g. [addrman] Selected IP:PORT from tried #34190

1. 
   GregTonoski commented at 12:43 pm on January 2, 2026: none

   Is there an existing issue for this?

   • I have searched the existing issues

   Current behaviour

   There are many logs like the examples below despite networkactive=0:

   1. 2025-12-31T12:24:47Z [addrman] Selected 34.75.109.94:8333 from tried
   2. 2025-12-31T12:24:47Z [tor] Error connecting to Tor control socket 2025-12-31T12:24:47Z [tor] Not connected to Tor control port 127.0.0.1:9051, retrying in 25.63 s
   3. 2025-12-31T12:28:43Z [net:error] Could not get best interface for default route: Element not found. (1168) 2025-12-31T12:28:43Z [net] portmap: Could not determine IPv4 default gateway

   Expected behaviour

   There isn’t any network activity and so no such logs.

   Steps to reproduce

   1. Start bitcoind.exe -networkactive=0

   Relevant log output

   bitcoind_addrman_win.txt

   How did you obtain Bitcoin Core

   Pre-built binaries

   What version of Bitcoin Core are you using?

   v29

   Operating system and version

   Windows 11

   Machine specifications

   No response

2. 
   willcl-ark commented at 9:51 am on January 13, 2026: member

   If you interpret “networkactive” to mean “this program will not perform any network-related activity” then “fixing” this would make sense. However of your interpretation is “toggle a connection to the bitcoin p2p network” then the current behaviour seems fine:

   • If you have networkactive and toggle it, then all bitcoin p2p connections are dropped
   • Toggle it again to re-enable connections

   Configuring pmp, running the addrman loop and making a connection to the tor control port in readiness for future connections doesn’t seem completely untoward, in my opinion.

   Curious what others think here though, as giving torControlThread and mapport_thread knowledge of the state of networkactive is pretty easy. I didn’t have a look at addrman yet though…

   edit: I did end up taking a look at what an implementation for this would look like for mapport and torcontroller here: https://github.com/bitcoin/bitcoin/compare/master...willcl-ark:bitcoin:refs/heads/respect-networkactive

   Seems to work ok.

3. willcl-ark added the label Bug on Jan 13, 2026
4. willcl-ark added the label Needs Conceptual Review on Jan 13, 2026
5. 
   davidgumberg commented at 7:16 pm on January 14, 2026: contributor

   Configuring pmp, running the addrman loop and making a connection to the tor control port in readiness for future connections doesn’t seem completely untoward, in my opinion.

   I agree, but I don’t think there is much advantage in doing those things when disconnected from the P2P network, no one will be surprised that Bitcoin Core isn’t doing those things when networkactive is set to false. https://github.com/bitcoin/bitcoin/compare/master...willcl-ark:bitcoin:refs/heads/respect-networkactive seems simple enough…

6. 
   brunoerg commented at 1:59 pm on January 15, 2026: contributor

   Curious what others think here though, as giving torControlThread and mapport_thread knowledge of the state of networkactive is pretty easy. I didn’t have a look at addrman yet though…

   I think these many selections from addrman is because we verify if the network is active at OpenNetworkConnection, so this addrman interation might come from ThreadOpenConnections.

Contributors
GregTonoski willcl-ark davidgumberg brunoerg

Labels
Bug Needs Conceptual Review