<p>Bitcoin Core 0.13.1 <a href="https://github.com/bitcoin/bitcoin/pull/8949" rel="nofollow noreferrer">preferentially maintains at least 4 outgoing peers</a> that advertise <code>NODE_WITNESS</code> support to avoid being partitioned. You are not only connecting to these nodes, more than 4 outgoing peers is coincidental or caused by those being other peers you recently connected to.</p>

<blockquote>
  <p>even though, according to bitnodes leaderboard, these nodes form a minority.</p>
</blockquote>

<p>Bitnodes only shows peers with listening sockets available. There is an unknown, greater number of nodes in existence which do not listen on a public port and will not be part of that leaderboard, but will connect to you. The preferential peering is exacerbating that effect, but is completely necessary. </p>

CC BY-SA 3.0
2016-12-01T15:58:55.350Z
Pull 8949 might give the impression in the wording or in the code that it is only 4, but in reality it is 100% as the 4 connections that are not forced to be 0.13.1 are eventually dropped and replaced with forced 0.13.1 nodes since the logic is such that once 4 connections are reached - it can connect only to other 0.13.1 nodes.
Rebroad
CC BY-SA 3.0
2016-12-27T21:23:36.737Z
That's not what the logic does.
Claris
CC BY-SA 3.0
2016-11-05T01:21:34.283Z
2016-11-05T02:54:37.423Z
2016-11-05T02:54:37.423Z
Claris
<p>I have my Core 0.13.1 node configured to connect to 16 nodes, and invariably I see it connected only to other 0.13.1 nodes, even though, according to bitnodes leaderboard, these nodes form a minority.</p>

<p>Why is the selection logic this restrictive?</p>

<p>I am also noticing my 0.13.1 node that accepts incoming connecting as relatively overloaded I/O-wise since it upgraded.</p>

<p>I can understand this selection logic being necessary once SegWit activates, but why already, given we don't know yet whether SegWit will activate?</p>

<p>Related: <a href="https://github.com/bitcoin/bitcoin/issues/9072" rel="nofollow noreferrer">https://github.com/bitcoin/bitcoin/issues/9072</a></p>

CC BY-SA 3.0
2016-11-04T13:19:39.353Z
I think I've had a few other nodes connected to mine yesterday, but I've also had the impression that it takes much longer to get incoming connections and when my node starts up, it almost immediately only has 0.13.1 and 0.13.99 nodes connected to it. – So, it seems likely that there is a strong preferential connecting, but not an exclusive connecting to 0.13.X clients.
Murch
<bitcoin-core><segregated-witness><node-services>
Why are 0.13.1 Core nodes connecting only to Witness (e.g. 0.13.1) nodes?
Rebroad
# Why are 0.13.1 Core nodes connecting only to Witness (e.g. 0.13.1) nodes?

(Asked by: username_0 on 2016-11-04)

I have my Core 0.13.1 node configured to connect to 16 nodes, and invariably I see it connected only to other 0.13.1 nodes, even though, according to bitnodes leaderboard, these nodes form a minority.

Why is the selection logic this restrictive?

I am also noticing my 0.13.1 node that accepts incoming connecting as relatively overloaded I/O-wise since it upgraded.

I can understand this selection logic being necessary once SegWit activates, but why already, given we don't know yet whether SegWit will activate?

Related: <https://github.com/bitcoin/bitcoin/issues/9072>

**Tags:** bitcoin-core, segregated-witness, node-services

> **Comments:**
> **username_1**: I think I've had a few other nodes connected to mine yesterday, but I've also had the impression that it takes much longer to get incoming connections and when my node starts up, it almost immediately only has 0.13.1 and 0.13.99 nodes connected to it. – So, it seems likely that there is a strong preferential connecting, but not an exclusive connecting to 0.13.X clients.  

---

## 1 answers

### Answer by username_2 on 2016-11-05. Score: 4

Bitcoin Core 0.13.1 [preferentially maintains at least 4 outgoing peers](https://github.com/bitcoin/bitcoin/pull/8949) that advertise `NODE_WITNESS` support to avoid being partitioned. You are not only connecting to these nodes, more than 4 outgoing peers is coincidental or caused by those being other peers you recently connected to.

> even though, according to bitnodes leaderboard, these nodes form a minority.

Bitnodes only shows peers with listening sockets available. There is an unknown, greater number of nodes in existence which do not listen on a public port and will not be part of that leaderboard, but will connect to you. The preferential peering is exacerbating that effect, but is completely necessary.

> **Comments:**
> **username_0**: Pull 8949 might give the impression in the wording or in the code that it is only 4, but in reality it is 100% as the 4 connections that are not forced to be 0.13.1 are eventually dropped and replaced with forced 0.13.1 nodes since the logic is such that once 4 connections are reached - it can connect only to other 0.13.1 nodes.  
> **username_2**: That's not what the logic does.  

---

