net: respect -onlynet= when making outbound connections #22834

vasild · 2021-08-30T13:14:00Z

Do not make outbound connections to hosts which belong to a network
which is restricted by -onlynet.

This applies to hosts that are automatically chosen to connect to and to
anchors.

This does not apply to hosts given to -connect, -addnode,
addnode RPC, dns seeds, -seednode.

Fixes #13378
Fixes #22647
Supersedes #22651

laanwj · 2021-08-30T13:20:36Z

Concept ACK, I think this makes onlynet closer to what users expect, clearing up all kind of exceptions that have to be documented. Thanks!

vasild · 2021-08-30T14:35:14Z

With this PR, one could use for example -onlynet=ipv6 -onion=127.0.0.1:9050 and Bitcoin Core will not automatically connect to .onion hosts. However one could later use the addnode RPC to manually connect to an .onion host. This matches the current behavior in master wrt other networks, e.g. -onlynet=ipv6 and later addnode to an ipv4 host.

jonatack

Concept ACK, initial drive-by review on github, will review/test soon

doc/tor.md

src/net.cpp

jonatack · 2021-08-30T15:51:28Z

(Feel free to ignore my comments until you re-push.)

Do you plan to add functional tests like in #22651?

DrahtBot · 2021-08-30T22:34:03Z

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

Conflicts

Reviewers, this pull request conflicts with the following ones:

#24205 (net, init, test: network reachability testing and safety improvements by jonatack)
#15423 (torcontrol: Query Tor for correct -onion configuration by luke-jr)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

vasild · 2021-08-31T12:57:09Z

Do you plan to add functional tests like in #22651?

It would be good. I wonder how to test this deterministically. I guess I would want to have an addrman with just addresses from one network and use onlynet another network and check that a connection is never attempted, or something like that.

ghost · 2021-08-31T15:19:44Z

Concept ACK

Started testing today and need to test lot of combinations with onlynet. Sharing things that I observed during basic tests:

onlynet=i2p with proxy=127.0.0.1:9050 does not create any outbound connections to onion nodes using PR branch however it connects to onion node with Master branch. ✅

1.1 Run node 1:
```
bitcoind -regtest=1 -port=18333 -rpcport=18222 -rpcuser=user1 -rpcpassword=pass1 -datadir=/home/prayank/node1 -debug=net
```
1.2 Run node 2:
```
bitcoind -regtest=1 -port=18777 -rpcport=18666 -rpcuser=user2 -rpcpassword=pass2 -onlynet=i2p -i2psam=127.0.0.1:7656 -proxy=127.0.0.1:9050 -datadir=/home/prayank/node2 -debug=net
```
1.3 Copy onion address for node 1 and add it in peers.dat for node2:
```
bitcoin-cli -rpcport=18666 -rpcuser=user2 -rpcpassword=pass2 addpeeraddress "6w724ckwacu2sdfitjr6otzfi4hfutxqqcc5mju2gc2ufguysb447gqd.onion" 18444
```
1.4 Wait for few seconds and node 2 will create an outbound connection with node 1 on Master branch. It should fail on PR branch.

Master branch: https://pastebin.com/raw/krvahBf7
PR branch: https://pastebin.com/raw/P6uwLtxf
Onion service and i2p service are not created when proxy=127.0.0.1:9050 is used. (Master and PR branch) ⚠️

Rspigler · 2021-09-01T02:44:10Z

Concept ACK! Glad there's a full fix for this now.

vasild · 2021-09-01T14:51:25Z

7b821b9d4c...0ea0de6438: optimize OutboundConnectionAllowedTo() for a fast lookup coz it is called frequently, plus some rewording in the docs.

vasild · 2021-09-01T15:07:51Z

@prayank23, thanks for looking into this! So all is working as expected. -logips=1 will improve your log output a tiny bit. I also tested this manually by adding a printout inside OutboundConnectionAllowedTo(), with -onlynet=i2p -onion=127.0.0.1:9050 it is called many times with *.onion addresses and returns false as expected.

A room for improvement (out of the scope of this PR): with -onlynet=X if addrman contains a small percentage of X addresses, CConnman::ThreadOpenConnections() will loop many times trying non-X addresses which get rejected either by the existent IsReachable() check or by the newly added OutboundConnectionAllowedTo(). It takes seconds to select an I2P address for example. CAddrMan::Select() could be smarter and take a onlynets argument and somehow return addresses that only belong to the requested networks fast.

naumenkogs · 2021-09-01T16:02:03Z

Concept ACK

ghost · 2021-09-01T19:13:34Z

Day 2 of testing onlynet

ipv4	ipv6	onion	i2p	logs	Comments
🔵				https://pastebin.com/raw/nq5kXqYK	No issues ✅
	🔵			https://pastebin.com/raw/Hqnz0nAP	No issues ✅
		🔵		https://pastebin.com/raw/9bwY0Nbw	No issues ✅
			🔵	https://pastebin.com/raw/mhW371kx	No issues ✅

So all is working as expected

Need to test more things. ~~onlynet=ipv6 did not work as expected today.~~

-logips=1 will improve your log output a tiny bit

Thanks. Will try this tomorrow.

CAddrMan::Select() could be smarter and take a onlynets argument and somehow return addresses that only belong to the requested networks fast.

Yes we can try this.

mzumsande · 2021-09-01T23:28:17Z

I wonder about the interactions of the new OutboundConnectionAllowedTo() with IsReachable(), which is how -onlynet also influences things - it seems complicated to have both OutboundConnectionAllowedTo() and IsReachable() doing similar things with subtle differences, and depending on the situation one or the other is effective.

My understanding is that IsReachable() will still be able to violate the -onlynet option sometimes (if -proxy , -onion in init.cpp or torcontrol.cpp call SetReachable() after the -onlynet arg was evaluated).
Because addrman acceptance is gated by IsReachable(), I think we could still accept addrs from networks excluded by -onlynet into addrman that we no longer would make outgoing connections to - leading to futile connection attempts.

Would it be possible as an alternative approach to get Reachable in line with -onlynet expectations (e.g. by moving the -onlynet block in init.cpp below the -onion and -proxy blocks and also not calling SetReachable() from torcontrol if -onlynet excludes onions?) Or would there be negative side effects with other callers of IsReachable()?

vasild · 2021-09-02T08:25:59Z

@prayank23 does the machine have an actual IPv6 connectivity? Do you see successful connections to IPv6 hosts when -onlynet= is not used? The text Network is unreachable is an actual system error, it does not come from Bitcoin Core.

ghost · 2021-09-02T10:30:25Z

Yes it was ipv6 connectivity issue. There were 2 issues: 1. One of my ISP didn't support ipv6 2. Had to change network adapter from NAT to bridged in VM. Checked connectivity on http://test-ipv6.com/

Updated logs above as ipv6 works fine. Will test onion-ipv4, onion-ipv6, i2p-ipv4, i2p-ipv6, i2p-onion and ipv6-ipv4 today.

vasild · 2021-09-02T12:51:24Z

@mzumsande, good insight! I think there are two distinct properties of a network:

Whether it is reachable (the current IsReachable() function). That is - do we have the means to connect to it if we wanted?
Whether we should choose hosts from that network for making automatic outbound connections (-onlynet=, or the newly added OutboundConnectionAllowedTo() function)

For example, a setup like -onlynet=ipv6 -onion=127.0.0.1:9050 should make the Tor network "reachable", but avoid automatically opening connections to it. However, manual connections using -connect, -addnode and -seednode to Tor hosts should be still possible, using the proxy given with -onion=. Makes sense?

Your comments make me think - should we only add addresses to addrman if they are both 1. and 2. (right now it is just 1.)? E.g.

             // Do not store addresses outside our network
-            if (fReachable)
+            if (fReachable && OutboundConnectionAllowedTo(addr))
                 vAddrOk.push_back(addr);

or also limit relay of 1. but not 2. addresses?

What about changing the limited property in the getnetworkinfo RPC reply?

bitcoin/src/rpc/net.cpp

Lines 574 to 575 in b997dd2

    
           obj.pushKV("limited", !IsReachable(network)); 
        
           obj.pushKV("reachable", IsReachable(network));

naumenkogs · 2021-09-02T17:09:22Z

I agree with @mzumsande. I find it confusing that we have two functions considering -onlynet (see how vfLimited is filled with onlynet).

ghost · 2021-09-03T11:15:53Z

It tried few combinations with onlynet and everything works as expected. Although I am still not sure about trade-offs involved in each of these. Things get even more complicated if user has incoming connections on multiple networks as discussed in IRC: https://www.erisian.com.au/bitcoin-core-dev/log-2021-09-01.html (260 2021-09-01T20:26:30)

This PR has limited scope and it does fix the issues with onlynet and proxy usage.

ACK 0ea0de6

Will reACK if suggestions discussed above are implemented and functional tests are added:

#22834 (comment)

Also not sure why addpeeraddress returns false in this case: https://bitcoin.stackexchange.com/q/109465/

vasild · 2021-09-03T16:25:18Z

@mzumsande, @naumenkogs, if we need not make a distinction between 1. and 2. (from #22834 (comment)), then an alternative approach is possible, similar to the one described above by @mzumsande (but not quite the same).

What do you think about this: vasild@46a9a79? Note that even with that, IsReachable() does not represent exactly -onlynet.

mzumsande · 2021-09-05T21:51:46Z

I didn't find a place we would need to make the distinction between the ability (1) and the willingness (2) to make outbound connections to networks. Also the status quo for IsReachable() before this PR, despite the name, is a mix of 1. and 2. because it is initially set by -onlynet user preference (2) and then possibly overruled based on the means to connect to a network (1):

For example, a setup like -onlynet=ipv6 -onion=127.0.0.1:9050 should make the Tor network "reachable", but avoid automatically opening connections to it.

Is this a relevant scenario, i.e. what should be the practical consequence of a network being "reachable" in this scenario when we wouldn't do automatic connections to it?

However, manual connections using -connect, -addnode and -seednode to Tor hosts should be still possible, using the proxy given with -onion=. Makes sense?

Yes, I agree. As far as I can see, all of the manual connection code is completely independent from IsReachable, so this shouldn't be affected by any of the discussed suggestions.

Your comments make me think - should we only add addresses to addrman if they are both 1. and 2. (right now it is just 1.)

I tend to think that this would make sense. I don't see the point of storing addresses in addrman when we won't connect to them - whether this is because we cannot or because we don't want to doesn't seem crucial to me.

What do you think about this: vasild/bitcoin@46a9a79? Note that even with that, IsReachable() does not represent exactly -onlynet.

On first sight, I like this approach. I don't quite understand why it is possible to just drop the SetReachable() in torcontrol.cpp.

I have been looking into the other call sites of IsReachable() besides connection opening and addrman acceptance to see how they would be affected by possible changes:
IsPeerAddrLocalGood() and AddLocal() both call IsReachable() and therefore might be affected. Considering that they deal with the address used for self-advertising (and thus for getting incoming connections) I don't really understand why they make use of IsReachable() in the first place. Shouldn't this affect only outbound connection logic?

practicalswift · 2021-09-06T09:12:47Z

Concept ACK

vasild · 2021-09-07T12:34:36Z

I didn't find a place we would need to make the distinction between the ability (1) and the willingness (2) to make outbound connections to networks.

The only one I can think of is this - it would be strange to display onion as not reachable in getnetworkinfo RPC, but to be able to open manual connections to it using addnode.

Also the status quo for IsReachable() before this PR, despite the name, is a mix of 1. and 2. because it is initially set by -onlynet user preference (2) and then possibly overruled based on the means to connect to a network (1):

Yes.

For example, a setup like -onlynet=ipv6 -onion=127.0.0.1:9050 should make the Tor network "reachable", but avoid automatically opening connections to it.

Is this a relevant scenario, i.e. what should be the practical consequence of a network being "reachable" in this scenario when we wouldn't do automatic connections to it?

It would be possible to reach the network by opening a manual connection. I am not sure if this is "relevant". Maybe it is exotic use case.

What do you think about this: vasild/bitcoin@46a9a79? Note that even with that, IsReachable() does not represent exactly -onlynet.

On first sight, I like this approach. I don't quite understand why it is possible to just drop the SetReachable() in torcontrol.cpp.

Hmm, maybe that is not a good idea - if -torcontrol=... -torpassword=... are given (without any of -onlynet, -proxy or -onion) then that code would have flipped the Tor network from not reachable to reachable. Is this desirable? If yes, then instead of removing SetReachable() from torcontrol.cpp it should be made conditional: if (!onion_restricted) {. However that variable onion_restricted is local in init.cpp so it would either have to be made global (:disappointed:) or OutboundConnectionAllowedTo() used instead of it. But we are looking into that potentially more invasive patch only because the co-existence of IsReachable() and OutboundConnectionAllowedTo() is confusing...

IsPeerAddrLocalGood() and AddLocal() both call IsReachable() and therefore might be affected. Considering that they deal with the address used for self-advertising (and thus for getting incoming connections) I don't really understand why they make use of IsReachable() in the first place. Shouldn't this affect only outbound connection logic?

I think the logic is this - if a network is not reachable then we cannot accept connections from it. "Reachable" in the broader English word meaning, not the stricter -onlynet meaning. For example, a host/OS may have support for both IPv4 and IPv6 but its ISP may only support IPv4. So, an operator would run -onlynet=ipv4 to avoid attempting connections to IPv6 hosts and from advertising an IPv6 address to which the rest of the world cannot connect.

Do not make outbound connections to hosts which belong to a network which is restricted by `-onlynet`. This applies to hosts that are automatically chosen to connect to and to anchors. This does not apply to hosts given to `-connect`, `-addnode`, `addnode` RPC, dns seeds, `-seednodes`. Fixes bitcoin#13378 Fixes bitcoin#22647 Supersedes bitcoin#22651

-BEGIN VERIFY SCRIPT- sed -i 's/\<proxyType\>/Proxy/g' $(git grep -l proxyType) -END VERIFY SCRIPT-

vasild · 2021-11-24T11:47:00Z

051c2554ca...0eea83a85e: rebase due to conflicts

Invalidates ACK from @prayank23

ghost

reACK 0eea83a

src/init.cpp

naumenkogs · 2021-12-01T11:21:12Z

utACK 0eea83a

Do not make outbound connections to hosts which belong to a network which is restricted by `-onlynet`. This applies to hosts that are automatically chosen to connect to and to anchors. This does not apply to hosts given to `-connect`, `-addnode`, `addnode` RPC, dns seeds, `-seednodes`. Fixes bitcoin#13378 Fixes bitcoin#22647 Supersedes bitcoin#22651 Github-Pull: bitcoin#22834 Rebased-From: 0ea0de6

jonatack

ACK 0eea83a code review, rebased to master, debug built, and did some manual testing with various config options on signet

Came across the onlynet issue again recently that this pull fixes.

This pull has been through quite a bit of review and has several ACKs. It may be good to have it in v23.

src/init.cpp

jonatack · 2022-01-30T21:27:19Z

src/init.cpp

+            return InitError(
+                _("Outbound connections restricted to Tor (-onlynet=onion) but the proxy for "
+                  "reaching the Tor network is not provided (no -proxy= and no -onion= given) or "
+                  "it is explicitly forbidden (-onion=0)"));


Manually tested hitting this error message. A test may be good in a follow-up.

A candidate for #24205?

A candidate for #24205?

Done, along with test coverage for the other proxy/onion/onlynet init errors.

jonatack · 2022-01-30T21:41:09Z

src/init.cpp

@@ -441,7 +441,7 @@ void SetupServerArgs(ArgsManager& argsman)
    argsman.AddArg("-onion=<ip:port>", "Use separate SOCKS5 proxy to reach peers via Tor onion services, set -noonion to disable (default: -proxy)", ArgsManager::ALLOW_ANY, OptionsCategory::CONNECTION);
    argsman.AddArg("-i2psam=<ip:port>", "I2P SAM proxy to reach I2P peers and accept I2P connections (default: none)", ArgsManager::ALLOW_ANY, OptionsCategory::CONNECTION);
    argsman.AddArg("-i2pacceptincoming", "If set and -i2psam is also set then incoming I2P connections are accepted via the SAM proxy. If this is not set but -i2psam is set then only outgoing connections will be made to the I2P network. Ignored if -i2psam is not set. Listening for incoming I2P connections is done through the SAM proxy, not by binding to a local address and port (default: 1)", ArgsManager::ALLOW_ANY, OptionsCategory::CONNECTION);
-    argsman.AddArg("-onlynet=<net>", "Make outgoing connections only through network <net> (" + Join(GetNetworkNames(), ", ") + "). Incoming connections are not affected by this option. This option can be specified multiple times to allow multiple networks. Warning: if it is used with non-onion networks and the -onion or -proxy option is set, then outbound onion connections will still be made; use -noonion or -onion=0 to disable outbound onion connections in this case.", ArgsManager::ALLOW_ANY, OptionsCategory::CONNECTION);
+    argsman.AddArg("-onlynet=<net>", "Make automatic outgoing connections only through network <net> (" + Join(GetNetworkNames(), ", ") + "). Incoming connections are not affected by this option. This option can be specified multiple times to allow multiple networks.", ArgsManager::ALLOW_ANY, OptionsCategory::CONNECTION);


Maybe s/outgoing connections/automatic outbound connections and s/incoming connections/inbound and manual connections/ in these three lines:

₿ git grep "Incoming connections\|. Incoming" doc/i2p.md:68:Make outgoing connections only to I2P addresses. Incoming connections are not doc/tor.md:56: -onlynet=onion Make outgoing connections only to .onion addresses. Incoming src/init.cpp:444: argsman.AddArg("-onlynet=<net>", "Make automatic outgoing connections only through network <net> (" + Join(GetNetworkNames(), ", ") + "). Incoming connections are not affected by this option. This option can be specified multiple times to allow multiple networks.", ArgsManager::ALLOW_ANY, OptionsCategory::CONNECTION);

Will do if I retouch.

Yes, can be as a follow-up. This seems RFM.

Done in #24468

…ections

…ated tor/i2p documentation a1db99a init, doc: improve -onlynet help and tor/i2p documentation (Jon Atack) Pull request description: including review feedback from bitcoin/bitcoin#22834 (comment) and bitcoin/bitcoin#24205 (comment) concerning `src/init.cpp`, `doc/tor.md` and `doc/i2p.md` - s/outgoing/automatic outbound/ - s/Incoming/Inbound and manual/ (are not affected by this option.) - s/only through network/only to network/ - s/this option. This option/this option. It/ - s/network types/networks/ and pick up a few nits in `doc/p2p-bad-ports.md` from bitcoin/bitcoin#23542 (review). ACKs for top commit: laanwj: ACK a1db99a w0xlt: ACK a1db99a theStack: ACK a1db99a Tree-SHA512: dd727904b9b3dadb16053e2b0350e6c0814ef68fb0cca7d34880b883123cfe3aa03b15813b40a863f6367d596d17ee4517eab55281cfe35cd00767b8a39593ca

…/i2p documentation a1db99a init, doc: improve -onlynet help and tor/i2p documentation (Jon Atack) Pull request description: including review feedback from bitcoin#22834 (comment) and bitcoin#24205 (comment) concerning `src/init.cpp`, `doc/tor.md` and `doc/i2p.md` - s/outgoing/automatic outbound/ - s/Incoming/Inbound and manual/ (are not affected by this option.) - s/only through network/only to network/ - s/this option. This option/this option. It/ - s/network types/networks/ and pick up a few nits in `doc/p2p-bad-ports.md` from bitcoin#23542 (review). ACKs for top commit: laanwj: ACK a1db99a w0xlt: ACK a1db99a theStack: ACK a1db99a Tree-SHA512: dd727904b9b3dadb16053e2b0350e6c0814ef68fb0cca7d34880b883123cfe3aa03b15813b40a863f6367d596d17ee4517eab55281cfe35cd00767b8a39593ca

…and safety 58a1479 test: passing -onlynet=onion with -onion=0/-noonion raises expected init error (Jon Atack) 7000f66 test: passing -onlynet=onion without -proxy/-onion raises expected init error (Jon Atack) 8332e6e test: passing invalid -onion raises expected init error (Jon Atack) d5edb08 test: passing invalid -proxy raises expected init error (Jon Atack) bd57dcb test: hoist proxy out of 2 network loops in feature_proxy.py (Jon Atack) afdf2de test: add CJDNS to LimitedAndReachable_Network unit tests (Jon Atack) 2b7a818 net, init: assert each network reachability is true by default (Jon Atack) Pull request description: Adds missing network reachability test coverage and an assertion during init, noticed while reviewing #22834: - assert during init that each network reachability is true by default - add CJDNS to the `LimitedAndReachable_Network` unit tests - hoist proxy out of two network loops in feature_proxy.py - test that passing invalid `-proxy` raises expected init error - test that passing invalid `-onion` raises expected init error - test that passing `-onlynet=onion` without `-proxy` and `-onion` raises expected init error - test that passing `-onlynet=onion` with `-onion=0` and with `-noonion` raises expected init error ACKs for top commit: vasild: ACK 58a1479 brunoerg: ACK 58a1479 dongcarl: Code Review ACK 58a1479 Tree-SHA512: bdee6dd0c12bb63591ce7c9321fe77b509ab1265123054e774adc38a187746dddafe1627cbe89e990bcc78b45e194bfef8dc782710d5b217e2e2106ab0158827

…verage and safety 58a1479 test: passing -onlynet=onion with -onion=0/-noonion raises expected init error (Jon Atack) 7000f66 test: passing -onlynet=onion without -proxy/-onion raises expected init error (Jon Atack) 8332e6e test: passing invalid -onion raises expected init error (Jon Atack) d5edb08 test: passing invalid -proxy raises expected init error (Jon Atack) bd57dcb test: hoist proxy out of 2 network loops in feature_proxy.py (Jon Atack) afdf2de test: add CJDNS to LimitedAndReachable_Network unit tests (Jon Atack) 2b7a818 net, init: assert each network reachability is true by default (Jon Atack) Pull request description: Adds missing network reachability test coverage and an assertion during init, noticed while reviewing bitcoin#22834: - assert during init that each network reachability is true by default - add CJDNS to the `LimitedAndReachable_Network` unit tests - hoist proxy out of two network loops in feature_proxy.py - test that passing invalid `-proxy` raises expected init error - test that passing invalid `-onion` raises expected init error - test that passing `-onlynet=onion` without `-proxy` and `-onion` raises expected init error - test that passing `-onlynet=onion` with `-onion=0` and with `-noonion` raises expected init error ACKs for top commit: vasild: ACK 58a1479 brunoerg: ACK 58a1479 dongcarl: Code Review ACK 58a1479 Tree-SHA512: bdee6dd0c12bb63591ce7c9321fe77b509ab1265123054e774adc38a187746dddafe1627cbe89e990bcc78b45e194bfef8dc782710d5b217e2e2106ab0158827

fanquake added the P2P label Aug 30, 2021

vasild mentioned this pull request Aug 30, 2021

tor: respect non-onion -onlynet= for outgoing Tor connections #22651

Closed

vasild mentioned this pull request Aug 30, 2021

doc, test: improve i2p/tor docs and i2p reachable unit tests #22648

Merged

jonatack reviewed Aug 30, 2021

View reviewed changes

doc/tor.md Outdated Show resolved Hide resolved

src/net.cpp Outdated Show resolved Hide resolved

This was referenced Aug 30, 2021

refactor: Clarify and disable unused ArgsManager flags #22766

Merged

refactor: Implement missing error checking for ArgsManager flags #16545

Draft

ghost mentioned this pull request Aug 31, 2021

Checkboxes for onlynet combinations bitcoin-core/gui#413

Open

vasild force-pushed the onlynet branch from 7b821b9 to 0ea0de6 Compare September 1, 2021 14:49

ghost mentioned this pull request Sep 16, 2021

cli: Display all proxies in -getinfo #22959

Merged

DrahtBot added the Needs rebase label Nov 24, 2021

vasild added 2 commits November 24, 2021 12:44

scripted-diff: rename proxyType to Proxy

0eea83a

-BEGIN VERIFY SCRIPT- sed -i 's/\<proxyType\>/Proxy/g' $(git grep -l proxyType) -END VERIFY SCRIPT-

vasild force-pushed the onlynet branch from 051c255 to 0eea83a Compare November 24, 2021 11:45

ghost approved these changes Nov 24, 2021

View reviewed changes

DrahtBot removed the Needs rebase label Nov 24, 2021

naumenkogs reviewed Dec 1, 2021

View reviewed changes

src/init.cpp Show resolved Hide resolved

jonatack approved these changes Jan 30, 2022

View reviewed changes

jonatack reviewed Jan 30, 2022

View reviewed changes

jonatack mentioned this pull request Jan 30, 2022

init, test: improve network reachability test coverage and safety #24205

Merged

maflcko added this to the 23.0 milestone Jan 31, 2022

laanwj merged commit 848b116 into bitcoin:master Mar 1, 2022

vasild deleted the onlynet branch March 2, 2022 07:14

sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Mar 2, 2022

Merge bitcoin#22834: net: respect -onlynet= when making outbound conn…

ca34ee9

…ections

jonatack mentioned this pull request Mar 3, 2022

init, doc: improve -onlynet help and related tor/i2p documentation #24468

Merged

jonatack mentioned this pull request Mar 9, 2022

23.x backports #24512

Merged

mzumsande mentioned this pull request Apr 24, 2022

Revert "Do not consider blocked networks local" #24835

Closed

ghost mentioned this pull request Sep 29, 2022

contrib: add vasild to trusted keys #25871

Closed

bitcoin locked and limited conversation to collaborators Mar 3, 2023

net: respect -onlynet= when making outbound connections #22834

net: respect -onlynet= when making outbound connections #22834

Uh oh!

Conversation

vasild commented Aug 30, 2021 • edited by laanwj Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

laanwj commented Aug 30, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vasild commented Aug 30, 2021

Uh oh!

jonatack left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

jonatack commented Aug 30, 2021

Uh oh!

DrahtBot commented Aug 30, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Conflicts

Uh oh!

vasild commented Aug 31, 2021

Uh oh!

ghost commented Aug 31, 2021 • edited by ghost Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Rspigler commented Sep 1, 2021

Uh oh!

vasild commented Sep 1, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vasild commented Sep 1, 2021

Uh oh!

naumenkogs commented Sep 1, 2021

Uh oh!

ghost commented Sep 1, 2021 • edited by ghost Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mzumsande commented Sep 1, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vasild commented Sep 2, 2021

Uh oh!

ghost commented Sep 2, 2021

Uh oh!

vasild commented Sep 2, 2021

Uh oh!

naumenkogs commented Sep 2, 2021

Uh oh!

ghost commented Sep 3, 2021 • edited by ghost Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vasild commented Sep 3, 2021

Uh oh!

mzumsande commented Sep 5, 2021

Uh oh!

practicalswift commented Sep 6, 2021

Uh oh!

vasild commented Sep 7, 2021

Uh oh!

vasild commented Nov 24, 2021

Uh oh!

ghost left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

naumenkogs commented Dec 1, 2021

Uh oh!

jonatack left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jonatack Jan 30, 2022

Choose a reason for hiding this comment

Uh oh!

vasild Jan 31, 2022

Choose a reason for hiding this comment

Uh oh!

vasild commented Aug 30, 2021 •

edited by laanwj

Loading

laanwj commented Aug 30, 2021 •

edited

Loading

DrahtBot commented Aug 30, 2021 •

edited

Loading

ghost commented Aug 31, 2021 •

edited by ghost

Loading

vasild commented Sep 1, 2021 •

edited

Loading

ghost commented Sep 1, 2021 •

edited by ghost

Loading

mzumsande commented Sep 1, 2021 •

edited

Loading

ghost commented Sep 3, 2021 •

edited by ghost

Loading

jonatack Mar 1, 2022 •

edited

Loading