<p>Nothing prevents this as it is impossible to distinguish whether the node that is connecting to you is the same one that you are already connected to. This is because one machine can run multiple node software or multiple instances of the same software and thus it can be multiple nodes on the network.</p>

<p>There's also no reason to block such a connection.</p>

CC BY-SA 4.0
2019-05-20T07:00:30.403Z
I see that there is no reason to block such a connection. However, as I see it, a node would benefit if it connects to another node (and not to a one it is already connected to). Can't we use the IP address?
Jan Telov
CC BY-SA 4.0
2019-05-20T15:24:28.790Z
No. IP addresses are not unique enough identifiers. Besides what I mentioned, there's also the issue of NATs. Two computers behind a NAT will have the same public IP address.
Ava Chow
CC BY-SA 4.0
2019-05-15T15:40:01.840Z
2019-05-15T15:40:01.840Z
Ava Chow
<p>Jan,</p>
<p>there is a mechanism that prevents Bitcoin Core from opening a new connection (making an outbound) to an address it is already connected to (irrelevant of whether the existent connection is inbound or outbound).</p>
<p>See the function <code>CConnman::AlreadyConnectedToAddress()</code>, how it is called from <code>CConnman::OpenNetworkConnection()</code> and the surrounding code.</p>
<p>This check, however, could allow to open an outbound even if an inbound from the same address exists in the following cases:</p>
<ol>
<li>When opening an outbound connection to RPC <code>addnode onetry</code>, RPC <code>addconnection</code>, <code>ADDR_FETCH</code> connections, connections to addresses given to <code>-connect</code> and <code>-addnode</code>. Then the port is also compared. So, for sure, we are not going to see an inbound connection from the node's listening port (e.g. <code>addr:8333</code>) during the check. Inbound connection are from some random port assigned by the remote node's operating system (e.g. <code>addr:54721</code>). In these cases the check would only prevent us from opening multiple outbound connections to the same node.</li>
</ol>
<p>In the other cases only the address is compared, without the port, so the check would detect an existent inbound from <code>addr:54721</code> when trying to connect to <code>addr:8333</code> and would cancel the opening of the connection. However:</p>
<ol start="2">
<li>There is a race in <code>CConnman::OpenNetworkConnection()</code>, if <code>addr</code> connects to us between the two:</li>
</ol>
<ul>
<li>check whether connected to <code>addr</code></li>
<li>if not, then open a connection to <code>addr</code></li>
</ul>
<p>This race is rare because the window is very small, but more likely if the network is slow and completing the connection takes some time, like could be with overlay networks, especially I2P.</p>

CC BY-SA 4.0
2022-11-23T11:52:59.407Z
2022-11-23T11:52:59.407Z
vasild
<p>I'm trying to figure out if we can create an outgoing connection to a inbound node (a node which we are already connected to, but the remote peer has initiated the connection). I know that this does not make much sense since we exchange information to inbound and outbound nodes. However, I have looked at the source code and did not find the code that prevents a node from doing that. Is anyone out there more successful?</p>

CC BY-SA 4.0
2019-05-15T13:34:19.620Z
I misread that. Nothing prevents what you describe.
Claris
<bitcoin-core-development><network><p2p><connection>
Can a Bitcoin node create an outgoing connection to a inbound node?
Jan Telov
# Can a Bitcoin node create an outgoing connection to a inbound node?

(Asked by: username_0 on 2019-05-15)

I'm trying to figure out if we can create an outgoing connection to a inbound node (a node which we are already connected to, but the remote peer has initiated the connection). I know that this does not make much sense since we exchange information to inbound and outbound nodes. However, I have looked at the source code and did not find the code that prevents a node from doing that. Is anyone out there more successful?

**Tags:** bitcoin-core-development, network, p2p, connection

> **Comments:**
> **username_1**: I misread that. Nothing prevents what you describe.  

---

## 2 answers

### Answer by username_2 on 2019-05-15. Score: 0 | Accepted answer

Nothing prevents this as it is impossible to distinguish whether the node that is connecting to you is the same one that you are already connected to. This is because one machine can run multiple node software or multiple instances of the same software and thus it can be multiple nodes on the network.

There's also no reason to block such a connection.

> **Comments:**
> **username_0**: I see that there is no reason to block such a connection. However, as I see it, a node would benefit if it connects to another node (and not to a one it is already connected to). Can't we use the IP address?  
> **username_2**: No. IP addresses are not unique enough identifiers. Besides what I mentioned, there's also the issue of NATs. Two computers behind a NAT will have the same public IP address.  

---

### Answer by username_3 on 2022-11-23. Score: 1

Jan,

there is a mechanism that prevents Bitcoin Core from opening a new connection (making an outbound) to an address it is already connected to (irrelevant of whether the existent connection is inbound or outbound).

See the function `CConnman::AlreadyConnectedToAddress()`, how it is called from `CConnman::OpenNetworkConnection()` and the surrounding code.

This check, however, could allow to open an outbound even if an inbound from the same address exists in the following cases:

1. When opening an outbound connection to RPC `addnode onetry`, RPC `addconnection`, `ADDR_FETCH` connections, connections to addresses given to `-connect` and `-addnode`. Then the port is also compared. So, for sure, we are not going to see an inbound connection from the node's listening port (e.g. `addr:8333`) during the check. Inbound connection are from some random port assigned by the remote node's operating system (e.g. `addr:54721`). In these cases the check would only prevent us from opening multiple outbound connections to the same node.

In the other cases only the address is compared, without the port, so the check would detect an existent inbound from `addr:54721` when trying to connect to `addr:8333` and would cancel the opening of the connection. However:

2. There is a race in `CConnman::OpenNetworkConnection()`, if `addr` connects to us between the two:

* check whether connected to `addr`
* if not, then open a connection to `addr`

This race is rare because the window is very small, but more likely if the network is slow and completing the connection takes some time, like could be with overlay networks, especially I2P.


---

